这条悄然改变每笔ACH支付检查方式的规则
今年，如果你的企业通过直接存款支付过工资、向供应商付款或收取客户款项，那么你已经在不知不觉中受到了这项你可能从未听说过的规则变更的影响。从2026年春季开始，Nacha——管理ACH网络的组织，该网络每年处理超过90万亿美元的直接存款、供应商付款和账单支付——开始要求几乎所有发起ACH交易的公司对这些支付进行主动欺诈监控。不是“应该”。而是“必须”，依据Nacha运营规则，该规则已由网络中的每家银行和支付处理器同意执行。
多年来，ACH欺诈预防主要停留在最佳实践讨论层面：银行推荐控制措施，一些公司采纳了这些措施，但执行力度参差不齐。这种情况之所以改变，是因为ACH信用推送欺诈——犯罪分子通过被入侵的电子邮件或伪造的供应商发票诱骗企业将资金发送到他们控制的账户——在支票欺诈和电汇欺诈越来越难以实施的情况下急剧增加。Nacha的回应是将监控写入规则手册本身，并设定了真实的截止日期和不遵守的严重后果。
以下是实际变化的内容、哪些人必须遵守，以及中小型企业需要采取什么行动。
分两阶段推出，简单说明
该规则并非一次性全面实施——Nacha分阶段推进，让网络中的大型参与者先行，为较小的发起方留出更多准备时间。
**第一阶段——2026年3月20日。**此阶段适用于所有发起存款金融机构（ODFI——代表企业提交ACH文件的银行），以及2023年发起或传输量超过600万条记录的任何发起方、第三方发送方或第三方服务提供商。实际上，这意味着大型工资处理商、大银行和高交易量支付平台必须首先启用欺诈监控。
**第二阶段——2026年6月19日（实际上为6月22日星期一，因为19日恰逢联邦假日）。**此阶段覆盖了所有其他主体：所有剩余的发起方、第三方发送方和第三方服务提供商，以及接收存款金融机构（RDFI——接收ACH存款入账的银行）。如果你的企业以任何交易量发起ACH支付，且你的银行或支付处理器尚未被第一阶段覆盖，那么这就是适用于你的截止日期。没有针对小企业的豁免条款。一家五人咨询公司通过ACH支付两名承包商的款项，在技术上与一家全国性零售商受同一规则约束，尽管对监控复杂程度的要求会随着发起方的规模和风险而调整。
除监控要求外，Nacha还标准化了两个银行对账单上显示的“公司入账描述”字段：PAYROLL，现在必须用于标识代表工资、薪水或类似报酬的ACH信用入账（技术上为预先安排付款和存款——PPD——信用），以及PURCHASE，用于消费者电子商务借记入账。两者均于2026年3月20日生效。如果你通过提供商发放工资，并注意到员工的工资单或银行对账单现在统一显示“PAYROLL”而不是你的公司名称或不一致的内部代码，这就是原因——这是一项有意的反欺诈措施，而非表面改动。一致且可预测的描述符使银行（和员工）更容易发现欺诈性的混淆交易。
“欺诈监控”实际要求你做什么
Nacha的规则并未为企业提供一套需要购买的固定软件清单。它要求的是一个基于风险的流程——有文档记录、合理设计以捕捉欺诈、并持续应用——而非任何单一的特定工具。实际上，根据银行和支付平台的实施情况，该流程需要涵盖以下几点：
- **账户所有权验证。**在释放资金之前，尤其是向新收款人或最近变更的账户付款时，应有一个流程确认收款账户确实属于你打算付款的个人或企业，而不仅仅是账号格式正确。
- **变更监控。**当供应商“更新”其银行信息，或员工的直接存款账户在工资发放前发生变更时，该事件应触发额外审查，而非自动更新。这是ACH欺诈最常见的载体：一封看似来自“应付账款”部门的可信邮件或一个被入侵的供应商账户，要求你将付款重定向到新账户。
- **异常检测。**异常大额付款、首次收款人、计划外或紧急工资发放，以及不符合企业正常模式的付款，应在释放前标记进行二次审查。
- **文档记录和审计追踪。**无论你使用何种流程，你都需要能够展示——包括日期、方法和结果——你进行了核查。如果没有实际拨打电话的记录，口头上的“我们总是打电话确认”是不够的。
- **升级流程。**当发现异常时应有文档化的处理路径：由谁审查，谁有权暂扣或拒绝付款，以及多快完成。
人工、单人“四眼”审批在交易量较大的情况下通常被认为不足以单独满足要求——期望的是控制措施一致且可重复，这通常意味着至少需要一定程度的自动化，即使只是在你的会计或工资软件中设置基于规则的标记，而非专门的欺诈平台。
谁负责，以及跳过会有什么后果
该规则将直接责任赋予发起方、第三方发送方和第三方服务提供商——但将你的ACH文件提交至网络的ODFI也被要求建立监督机制，这意味着你的银行有充分的动机确保你实际上在合规，而不仅仅是假设你合规。如果你使用工资提供商、发票平台或支付处理器代表你发起ACH交易，请直接询问他们：他们是否已符合第二阶段Nacha合规要求，以及如果你的银行提出要求，他们能提供什么验证证据？
不合规的后果有两个方向。首先，存在直接风险：违反Nacha规则可能面临罚款，且屡次或严重违规可能危及银行或处理器发起ACH交易的能力——如果你的提供商失去该权限，这将波及到你。其次，对大多数小企业而言更直接相关的是欺诈风险本身。根据Nacha规则，未能对付款进行合理谨慎验证的发起方，在付款被证实为欺诈时，相比遵循了文档化流程的发起方，可能承担更多损失。换句话说，监控要求不仅仅是监管层面的打勾——跳过它可能意味着你的企业必须吞下一笔本可通过文档化验证流程避免或转移的欺诈损失。
小企业实用合规清单
你不需要企业级欺诈平台就能满足该规则的精神。几个具体步骤即可覆盖大部分期望：
- **询问你的银行和工资/支付提供商他们做了什么改变。**许多银行已将监控自动集成到其现有ACH发起门户中——了解你是否受其控制措施覆盖，还是需要在其之上运行自己的额外层级。
- 写下你的验证流程，即使很简单。“任何新供应商银行账户，或对现有账户的任何变更，在首次付款前均通过已知号码进行电话确认”就是一项真实、有文档记录、基于风险的控制。关键在于它是书面化的、被一致遵循的，并能产生记录。
- **绝不仅凭电子邮件或发票更新付款信息。**这一单一习惯能阻止大多数商业电子邮件入侵和供应商冒充欺诈，而这正是该规则针对的欺诈模式。
- **将工资和供应商变更标记给第二审查人。**如果你是单人运营，这可能意味着新银行账户在收到首笔付款前有固定的24小时延迟，以便你有时间独立验证。
- **保留核查记录。**一个简单的日志——日期、验证内容、方式和执行人——对大多数小企业风险概况而言已足够，并且在付款日后发生争议时能提供佐证。
记账在欺诈预防中的角色
欺诈监控和清晰的记账解决的是重叠的问题。当你的账目足够及时，能够注意到不熟悉的收款人或与正常供应商模式不符的金额时，被重定向至欺诈账户的付款更容易被快速发现——在资金无法追回之前。每周或每月对账的企业，而非每季度，往往能在仍有机会通过银行追回款项时捕捉到异常。
这是保持会计记录透明且易于审计而非锁在只在报税时打开的黑盒工具中的更平实理由之一。Beancount.io为你提供纯文本、版本控制的会计，因此每笔交易——包括你发起的每笔ACH支付——都是账本中可审查、可比较的一行，而非埋藏在他人数据库中的记录。免费开始使用，体验随时全面掌握你的账目，而不仅仅是在问题已经发生时。