Ostorlab 徽标
定价
合作伙伴
登录预约演示
预约演示

CBUAE 第 2176 号通知：证明您的移动银行应用能够抵御欺诈。

阿联酋法律将健全的欺诈预防和检测规定为持牌金融机构的法定义务，阿联酋中央银行（CBUAE）的第 2176 号通知则聚焦移动银行欺诈。CBUAE 的公开规则已对认证、会话、API、设备防护和测试提出了期望。Ostorlab 测试您应用的防御在已 Root 和已越狱的设备上、登录之后以及处理资金流转的 API 中的实际表现。

  • 检查 Root 和越狱检测、防篡改和反插桩，以及这些防护触发时应用如何响应
  • 使用您的测试账户测试登录、一次性验证码、增强验证和会话处理
  • 即使启用 TLS 证书固定，也能沿着应用深入支付 API
  • 每项失效都以绕过证据或可重放的漏洞利用作为证明
扫描您自己的应用预约演示

从 App Store 或 Google Play 免费扫描您的应用，无需登录。

适用对象
阿联酋境内的持牌金融机构
法律依据
2025 年第 6 号联邦法令第 149 条，自2025年9月16日起生效
第 2176 号通知的重点
移动银行欺诈
通知状态
未在公开的 CBUAE 规则手册中发布
关键日期

移动渠道背后的 CBUAE 规则

第 2176 号通知建立在已生效多年的规则之上。以下日期对应本页引用的公开文本。

  1. 2020年10月30日

    《储值工具条例》

    针对储值工具的技术风险规则，也适用于开展储值业务的持牌银行。

  2. 2021年6月6日

    《零售支付服务和卡组织条例》

    面向支付服务提供商的技术风险、认证和会话规则，附件二提供最佳实践指南。

  3. 2021年11月15日

    赋能技术指南

    关于 API 的指南，包括认证、多因素认证和年度独立测试。

  4. 2025年9月16日

    2025 年第 6 号联邦法令

    第 149 条将健全的欺诈预防和检测规定为持牌金融机构的法定义务。

  5. 日期未公开

    第 2176 号通知

    针对受监管机构的移动银行欺诈应对行动。该通知未在公开的规则手册中发布。

  6. 每季度

    向 CBUAE 报告

    与欺诈相关的投诉以及安全和在线系统中的明显漏洞按季度报告，欺诈报告则每年于1月31日前提交。

CBUAE 的要求

将 CBUAE 的欺诈与安全规则应用于您的移动应用

第 2176 号通知与 CBUAE 关于欺诈、消费者保护、支付和技术风险的公开规则并行。每条规则都说明：文本的内容、它对移动银行应用意味着什么、Ostorlab 如何提供帮助，以及哪些工作仍由您的团队负责。

  1. 2025 年第 6 号联邦法令，第 149 条

    实施健全的欺诈预防与检测

    文本的内容

    持牌金融机构必须实施健全的欺诈预防和检测机制，保护客户免受未经授权的交易、社会工程、身份盗用及其他欺诈的侵害。CBUAE 可以为数字银行制定最低安全标准（包括认证协议），各机构必须在其设定的期限内实施其规定的预防措施。

    来源：2025 年第 6 号联邦法令，第 149 条

    对您的移动应用意味着什么

    欺诈预防是一项法定义务，而最低控制措施由 CBUAE 设定。对大多数银行而言，移动应用是客户进行认证和支付的地方，因此许多此类控制措施都位于应用中。

    Ostorlab 如何提供帮助

    Ostorlab 测试应用及其 API 中与欺诈相关的控制措施：认证、增强验证、会话处理、设备防护以及支付背后的业务逻辑。

    仍由您负责的部分

    交易监控、反欺诈运营，以及满足 CBUAE 设定的期限。

  2. 《消费者保护标准》，第 6.1.1.4 条和第 6.1.1.8 条

    保障每个服务渠道的安全

    文本的内容

    在所有服务渠道中提供安全、可靠和保密的环境。保障数字交易处理和控制的安全，实施详细的活动监控，并按照中央银行关于加强数字渠道的要求，改进消费者身份识别方法。

    来源：《消费者保护标准》，第 6.1.1.4 条和第 6.1.1.8 条

    对您的移动应用意味着什么

    移动应用是一个服务渠道。它存储和发送的数据，以及它发起的交易，都需要从设备到后端的全程保护。

    Ostorlab 如何提供帮助

    Ostorlab 在本地存储、缓存、日志和截图中查找会话令牌和个人数据，检查会削弱传输和会话保护的错误配置，并测试交易背后的 API。

    仍由您负责的部分

    活动监控以及您所选择的身份识别方法。

  3. 《消费者保护标准》，第 6.1.1.7 条；《零售支付服务和卡组织条例》，第 13 条

    实施强认证，并对高风险操作再次认证

    文本的内容

    对电子服务采用不止一种身份验证凭证。对于支付服务提供商，高风险交易须采用多因素认证，并在每笔此类交易前进行重新认证（例如双因素认证），包括超过预设限额的支付和个人联系方式的变更。

    来源：《消费者保护标准》，第 6.1.1.7 条；《零售支付服务和卡组织条例》，第 13 条

    对您的移动应用意味着什么

    针对收款人变更、限额提高和联系方式变更的增强验证，正是欺诈者试图跳过的控制措施。无论应用发送什么内容，这些控制都必须在服务器端有效。

    Ostorlab 如何提供帮助

    Ostorlab 使用您的测试账户完成短信、电子邮件或 TOTP 一次性验证码，测试 MFA 强制执行和增强验证流程（包括攻击者试图操纵它们的方式），以及账户变更背后的 API 调用。

    仍由您负责的部分

    选择认证方法和设定交易限额。

  4. 《零售支付服务和卡组织条例》，第 13 条

    限制登录尝试、会话和一次性密码有效期

    文本的内容

    限制登录和认证尝试的次数，实施超时控制和认证有效期限制，将一次性密码的有效期保持在严格必要的最短时间内，并在移动应用与验证密码的系统之间对密码进行端到端加密。

    来源：《零售支付服务和卡组织条例》，第 13 条

    对您的移动应用意味着什么

    这些都是具体、可测试的设置：失败尝试后的锁定、会话过期、一次性密码的有效期和重放，以及传输中的密码保护。

    Ostorlab 如何提供帮助

    认证测试覆盖登录和注销、令牌刷新、超时、会话失效和 MFA 强制执行，流量分析则显示凭据如何从应用传输到后端。

    仍由您负责的部分

    策略参数本身，例如锁定阈值和一次性密码有效期。

  5. 《零售支付服务和卡组织条例》附件二

    将客户设备视为已暴露

    文本的内容

    CBUAE 面向支付服务提供商的指南指出，应假定客户设备暴露于安全漏洞之下，并采取措施防范未经授权的设备访问、恶意软件、已被入侵或不安全的移动设备以及未经授权的移动应用。

    来源：《零售支付服务和卡组织条例》附件二

    对您的移动应用意味着什么

    已 Root 的手机、重新打包的应用和运行时挂钩工具，正是银行恶意软件的运行条件。防护措施应做出响应，而不仅仅是检测。

    Ostorlab 如何提供帮助

    Mobile Shielding Scan 在已 Root 和已越狱的环境中运行应用，尝试绕过 Root 和越狱检测、防篡改、反插桩以及 TLS 证书固定，并显示应用是会阻止业务流程、拒绝启动，还是继续运行。您将获得加固评分和绕过证据。

    仍由您负责的部分

    选择和配置您的加固或运行时防护产品。

  6. 《金融机构采用赋能技术指南》，API：设计，3.11 至 3.18

    保护您的 API，并每年进行独立测试

    文本的内容

    使用访问管理和认证，确保只有获得授权的各方才能访问 API 资源，并实施认证，使攻击者无法攻破令牌或冒用其他用户的身份。在客户首次访问使用 API 的在线服务时使用多因素认证，分离管理员和用户角色，并限制用户可请求的资源大小或数量。独立职能部门或外部专家应至少每年开展一次漏洞评估和渗透测试。

    来源：《金融机构采用赋能技术指南》，API：设计，3.11 至 3.18

    对您的移动应用意味着什么

    应用背后的 API 需要与应用同等的审查：至少每年由独立方测试一次，最好在每次发布时都进行测试。

    Ostorlab 如何提供帮助

    即使启用 TLS 证书固定，Ostorlab 也能拦截应用流量，测试 API 是否存在失效的授权（BOLA、BFLA、IDOR）、令牌和会话的滥用，以及枚举、重放和自动化等滥用行为，并为每项发现提供请求和响应证据。

    仍由您负责的部分

    选择由谁执行年度独立评估，以及 API 设计。

  7. 《储值工具条例》，第 12 条；《零售支付服务和卡组织条例》附件二

    发布前审查代码并进行测试

    文本的内容

    采用安全开发标准和基于风险的源代码审查，包括自动化分析。只有经过充分测试并获得批准的系统才应进入生产环境，测试应覆盖业务逻辑和安全控制。使用自动化工具和人工技术定期开展漏洞评估，并定期评估是否需要开展渗透测试和网络攻击模拟测试。

    来源：《储值工具条例》，第 12 条；《零售支付服务和卡组织条例》附件二

    对您的移动应用意味着什么

    应用的每个版本在上架商店之前都应通过自动化安全测试，高风险变更还应进行更深入的测试。

    Ostorlab 如何提供帮助

    Mobile SAST 分析二进制文件（包括嵌入的 SDK），Mobile DAST 测试运行中的应用，两者都在 CI/CD 中运行。AI 智能体渗透测试则测试支付和账户流程的业务逻辑。

    仍由您负责的部分

    人工审查、用户验收测试、职责分离和发布审批。

  8. 《消费者保护标准》，第 5.1.1.45 条、第 6.2.1.11 条和第 6.2.3.3 条

    能够证明您的控制措施是安全的

    文本的内容

    如果应用了适当且安全的验证程序，交易即被视为已获授权，除非消费者能够提出合理怀疑。对于因其安全控制被突破而造成的直接损失，机构可能须承担责任，并且必须每季度向中央银行报告其安全和在线系统中的明显漏洞。

    来源：《消费者保护标准》，第 5.1.1.45 条、第 6.2.1.11 条和第 6.2.3.3 条

    对您的移动应用意味着什么

    当出现有争议的交易或损失索赔时，能否证明您的验证程序安全且经过测试至关重要。

    Ostorlab 如何提供帮助

    扫描结果、附有复现步骤的发现以及复测结果，为您逐个版本留下注明日期的记录，说明应用的控制措施如何接受测试和修复。

    仍由您负责的部分

    争议处理流程、季度报告以及法律评估。

  9. CBUAE 第 2176 号通知，未公开

    第 2176 号通知：应对移动银行欺诈

    文本的内容

    第 2176 号通知为 CBUAE 监管的机构规定了应对移动银行欺诈的行动。该通知未在公开的 CBUAE 规则手册中发布，因此本页不引用其内容。

    来源：CBUAE 第 2176 号通知，未公开

    对您的移动应用意味着什么

    像对待上述公开规则一样对待通知中的每一点：将其与应用或后端中的某项控制、某项测试和某位负责人关联起来。

    Ostorlab 如何提供帮助

    在您完成通知的对应梳理后，Ostorlab 可以测试其涵盖的应用和 API 控制措施，并为每一项提供证据。

    仍由您负责的部分

    阅读通知、将其与您的控制措施对应，以及向 CBUAE 报告。

本页概述了 CBUAE 的公开文本，核对日期为2026年9月27日。部分文本仅适用于特定类型的牌照，已在文中注明。本页不构成法律意见。

对应关系

逐项梳理 CBUAE 规则中的控制措施

CBUAE 公开文本所指向的控制措施、Ostorlab 如何在您的应用及其 API 中测试这些控制，以及您可以留存的证据。

控制措施Ostorlab 如何提供帮助您留存的证据
针对已被入侵设备的防护零售支付条例，附件二在已 Root 和已越狱的环境中运行应用，并尝试绕过 Root 和越狱检测。 详情 加固评分，以及每项失效防护的绕过证据
针对篡改和重新打包的防护零售支付条例，附件二修改二进制文件，并检查应用是否阻止执行。 详情 防篡改的通过/未通过评级
针对运行时挂钩的防护零售支付条例，附件二注入调试器和挂钩，并调整尝试方式以突破反插桩防御。 详情 哪些防护有效、哪些被绕过的证据
多因素认证以及高风险操作的重新认证消费者保护标准 6.1.1.7；零售支付条例，第 13 条使用一次性验证码登录，测试 MFA 强制执行和增强验证流程，以及其背后的 API 调用。 详情 有关登录和增强验证流程的发现，附复现步骤
登录尝试、超时和一次性密码有效期零售支付条例，第 13 条测试登录和注销、令牌刷新、超时和会话失效。 详情 会话和令牌相关发现，附请求和响应日志
API 认证、令牌安全和访问控制赋能技术指南，3.11 至 3.17即使启用 TLS 证书固定也能拦截流量，并测试授权、令牌滥用以及枚举和重放等滥用行为。 详情 每项 API 发现的请求和响应证据
设备上和传输中的数据保护消费者保护标准 6.1.1.4在存储、缓存、日志和截图中查找令牌和个人数据，并检查传输保护。 详情 文件系统证据，显示写入了什么、写入位置和时间
发布前的代码审查和测试储值工具条例，第 12 条；零售支付条例，附件二在 CI/CD 中运行 Mobile SAST 和 DAST，并由 AI 智能体对业务逻辑进行渗透测试。 详情 每个构建的扫描结果，以及每个 AI 智能体发现的可重放漏洞利用
应用中的硬编码凭据消费者保护标准 6.1.1.4在应用包中查找 API 密钥、令牌和凭据，并验证它们是否可用。 详情 经过验证的密钥，以及它们暴露的权限和服务
安全且经过测试的控制措施记录消费者保护标准 5.1.1.45、6.2.1.11、6.2.3.3保存每个版本的扫描结果、工单和复测。 注明日期的扫描历史、工单和复测结果

Ostorlab 测试应用及其 API 中的控制措施。交易监控、反欺诈运营、客户安全意识教育以及向 CBUAE 报告仍由您的团队负责。

行动计划

需要在应用中测试的移动端反欺诈控制

面向安全和反欺诈团队的实用清单。请结合您持有的第 2176 号通知副本使用。

  1. 已被入侵的设备

    在已 Root 和已越狱的设备上运行应用，检查防护是否触发以及应用是否做出响应。

  2. 重新打包和被挂钩的应用

    尝试运行修改过的版本和运行时挂钩，确认应用拒绝运行或阻止敏感流程。

  3. 高风险操作的增强验证

    检查添加收款人、变更联系方式和超出限额时是否都需要重新认证，并由服务器强制执行。

  4. 登录与一次性密码设置

    验证失败尝试后的锁定、会话超时、一次性密码有效期和防重放保护。

  5. 支付背后的 API

    测试每个支付和账户 API 的授权，包括请求其他客户数据和重复请求的情况。

  6. 遗留在设备上的数据

    在存储、缓存、日志和截图中查找令牌和个人数据，并查找硬编码在应用中的凭据。

  7. 年度独立测试

    按照赋能技术指南的要求，规划至少每年一次针对您 API 的独立漏洞评估和渗透测试。

  8. 用于报告的证据

    保存每个版本的结果和复测，为季度报告和争议交易的处理提供支持。

此清单仅为建议，并非 CBUAE 模板，也不构成法律意见。

平台

本页涉及的能力

每项能力都有详细介绍页面。

受到银行和金融科技企业的信赖，包括

  • Nubank
  • Bread Financial
  • PNC
Gartner Peer Insights 评分 4.8/5已通过 SOC 2 Type II 审计

来源

本页所依据的官方文本，核对日期为2026年9月27日。

FAQ

常见问题

关于覆盖范围、部署配置以及结果如何送达您团队的直接解答。

没有找到答案？预约演示或联系我们。

检查您的移动银行应用的反欺诈防御

先从应用商店免费扫描您的应用，或预约演示，与我们的团队一起运行加固测试和登录后测试。

扫描您自己的应用预约演示