导致审计失败的审批竟然来自你自己的团队。以下是如何证明是谁做的决定，以及原因。

想象一下审计过程。审核员随机抽取了四十份客户档案。第二十三份档案中的客户，其面部与政府记录中的照片不符。审核失败。然而，该账户仍然开通，并且已经持续转账五个月了。

有人批准了。审计员问了三个问题：是谁批准的？依据是什么？他们有权这样做吗？

你们团队通过一个共享的管理员账号登录后台，所以第一个答案是“运营”。没有相关说明，所以第二个答案是猜测。使用该账号登录的每个人都可以审批任何事项，所以第三个答案是“是”，这是三个答案中最糟糕的一个。

没有发生黑客攻击。也没有诈骗分子绕过你们的审核。控制措施运转正常，只是你们内部有人为了某个客户而关闭了这套系统。这就是合规运营中的内部风险，而且大多数情况下并不违法。这只是帮个忙，在繁忙的周五走了捷径，或者是为了完成业绩目标。

为什么审计员会问“谁做的决定？”

衡量你的标准假定你的员工是风险的一部分。 FATF 第 18 条建议 （在新标签页中打开）要求金融机构开展反洗钱计划，其解释性说明指出，这些计划应包括内部政策、程序和控制措施、招聘员工时的筛选程序、持续培训以及“独立的审计职能来测试系统”。

巴塞尔委员会关于健全洗钱风险管理的指导原则 （在新标签页中打开）描述了三道防线，内部审计是第三道。该指导原则要求审计部门评估的内容之一是“银行员工执行银行政策和程序的有效性”。该指导原则还指出，记录应足够完善，以便在发生争议、法律诉讼或调查时提供审计追踪。

因此，审计人员不仅要检验你的审核机制是否有效，还要检验你的员工是否执行了审核，以及你是否能够证明这一点。即使某个决策本身是正确的，但如果你无法证明其执行情况，那么这个决策就无法通过审核。

有一些证据表明，内部控制措施失效的情况很常见，但这指的是针对雇主的欺诈行为，而不是合规审批方面的问题。 ACFE 《2024年职业欺诈：致各国报告》 （在新标签页中打开）研究了来自138个国家和地区的1921个案例。报告指出，其中32%的案例主要归因于内部控制的缺失，另有19%的案例是由于现有控制措施被凌驾于其上造成的。典型的案例在被发现前持续了12个月。由于我们尚未找到非洲市场中类似质量的合规性凌驾案例数据，因此我们不提供相关数据。

四个控件可以回答这个问题

这些都不是什么新鲜事。 NIST SP 800-53 （在新标签页中打开）是美国政府的安全控制目录，即使您不受其约束，它也是一份有用的简明语言参考资料。

• 最小权限原则。该控制要求您仅允许完成指定任务所必需的“授权访问”。在合规团队中，这意味着阅读警报的人员不能同时更改触发警报的规则。

• 敏感操作需由第二人负责。 NIST 职责分离原则“旨在防止滥用授权权限，并有助于降低非串谋恶意活动的风险”。一个人可以犯错或帮忙，但必须由两个人同意。

• 每人一个登录账号，并启用双重身份验证。该目录要求您为每个用户提供唯一标识，并对特权账号启用多重身份验证。共享登录账号会使所有其他控制措施失效，因为日志只能显示账号名称。

• 一份包含人员姓名的审计追踪记录。审计记录应明确事件经过、时间、地点、结果以及相关人员的身份。

那看起来是什么样的呢？ Toden

以下是每个控件与当前产品的对应关系。

• 角色。每个人都只能拥有一个角色，角色是一组您选择的权限。批准或拒绝验证需要verifications:review推翻欺诈判定需要fraud_prevention:override不断变化的筛查需求screening:manage改变工作流程需要workflows:manage内置的成员和查看者角色均为只读角色。权限由服务器进行检查，任何人不得授予自己不拥有的权限。

• 一个始终可见的覆盖选项。当审核员批准验证后，验证内容不会被重写。其检查状态会继续显示检查结果，状态历史记录会列出每次更改，包括更改者和更改时间。审核员可以添加备注说明更改原因，该备注会保存在您的审核日志和时间轴中。

• 控件已关闭。工作流程 AML 关闭筛选功能不会影响任何人，因此这项更改需要单独命名。发布工作流程会记录在审计日志中。关闭整个组织的筛选功能需要获得单独的许可和明确的确认，并且也会被记录。

• 双因素登录。成员可以使用身份验证器应用程序代码或密码登录。组织可以要求所有成员都启用双因素登录，并且可以随时撤销任何会话。

• 审计日志。每条记录包含操作人员当时的姓名和电子邮件地址、角色、操作、受影响的记录以及 IP 地址。该日志仅支持追加写入：无法通过控制台或系统编辑或删除记录。 API 它不包含任何ID号码、图像或机密信息，因此您可以将其交给审计人员。操作 Toden 支持记录会出现在您的日志中，并会进行相应标记。

• 一份报告需要两个人共同撰写。撰写可疑活动报告的人绝不能是提交报告的人。我们在“撰写可疑活动报告”部分涵盖了报告本身，在“警报分诊和案件管理”部分则涵盖了报告提交前的相关工作。

什么 Toden 不这样做

限制比功能更重要。

• 它仅强制第二个人执行一项操作：提交报告。对于审批和权限覆盖，权限分离则取决于您设计的角色。如果一个人拥有所有权限，那么他仍然可以执行所有操作。

• 这阻止不了意志坚定的内部人员。拥有相应权限的审核员可以批准未通过的审核。什么？ Toden 这样做是为了确保审批结果带有他们的名字，并且失败的审核记录会保留下来。

• 它无法判断两个人是否共用一个登录账号。启用双因素认证会增加账号共享的难度，但并不能完全杜绝共享，禁止共享账号的政策由您制定。

• 后端通过以下方式做出的决策 API 已记录在案 API 关键在于密钥，而非具体的人。是谁按下了你系统里的按钮，记录在你自己的日志中，而不是我们的日志里。参见“公开”和“秘密”部分。 API 钥匙。

• 审计日志涵盖 Toden 它对你的核心银行系统、电子表格或通过聊天消息收到的指令一无所知。

• Toden 不成立 SOC 2 或 ISO 今天已获得ISO 27001认证。我们的安全页面上有相关信息，并列出了现有的控制措施。

各国监管机构对内部控制、员工审查和记录保存的要求各不相同。我们已引用了以下内容： FATF 巴塞尔委员会和 NIST 这里指的是尼日利亚中央银行或其他任何国家监管机构，而非尼日利亚中央银行。这并非针对您个人情况的法律建议。

本周需要检查的五件事

• 每个人都有自己的登录账号吗？先统计账号数量，再统计人数。

• 双因素认证是所有人必须启用，还是只是推荐启用？

• 谁有权批准失败的支票？批准支票的人员名单是否比可以查看支票的人员名单更短？

• 修改规则的人能否同时清除由此引发的警报？

• 请选择上个月的一项审批结果。你能否在五分钟内说出是谁批准的，以及批准的原因？

如果最后一个答案是否定的，那么审计员将调取该文件。

想看看你的工作区里谁能做什么吗？打开 Toden 控制台 （在新标签页中打开）或阅读说明 Toden 处理安全问题。