Zero Clover

免责声明

• 本文旨在介绍金融系统相关的技术原理。所有内容仅用于学习与信息参考，不构成任何投资、金融、法律、会计或税务建议。
• 信息可能基于公开资料与作者理解，或存在不完整、非最新或错误之处；相关标准、接口、法规与行业实践会随时间变化。我们不对内容之准确性、完整性或适用性作出任何明示或暗示保证。
• 在设计、开发、部署或运营任何金融系统、产品或流程前，读者应独立进行合规评估并遵守适用法律法规（包括但不限于 AML/CFT、KYC/KYB、数据与隐私保护、消费者保护、制裁与可疑交易报告、资金传输 / 支付机构许可等），并咨询具备资质的专业人士或主管监管机构。
• 提及的机构、标准组织、网络与商标仅为说明之用，相关权利归其权利人所有。除非另有明确说明，作者与前述主体不存在代理、背书或合作关系。
• 在适用法律允许的最大范围内，我们不对因依赖或使用本文内容所致的任何直接、间接、附带或后果性损失承担责任。
• 监管要求因司法辖区而异，读者应结合所在地法律与政策进行解读与合规。
• 本文可能随时更新，恕不另行通知。

Disclaimer

• This article explains technical principles of financial systems (including but not limited to payments, clearing, settlement, account architectures, card networks, and digital assets). It is provided for educational and informational purposes only and does not constitute investment, financial, legal, accounting, or tax advice.
• The content may rely on public sources and the author’s understanding and may be incomplete, outdated, or contain errors. Standards, APIs, regulations, and industry practices change over time. No warranty—express or implied—is made regarding accuracy, completeness, or fitness for purpose.
• Before designing, developing, deploying, or operating any financial system, product, or process, you must conduct an independent compliance assessment and follow applicable laws and regulations (including, without limitation, AML/CFT, KYC/KYB, data/privacy, consumer protection, sanctions and suspicious activity reporting, and money transmission/payment licensing). Consult qualified professionals or relevant regulators.
• References to organizations, standards bodies, networks, and trademarks are for illustration only and belong to their respective owners. Unless expressly stated, no agency, endorsement, or partnership is implied.
• To the maximum extent permitted by law, we are not liable for any direct, indirect, incidental, or consequential loss arising from reliance on or use of this content.
• Regulatory obligations vary by jurisdiction. Readers should interpret and implement in light of local laws and policies.
• This material may be updated at any time without prior notice.

---

本文的部分内容使用了生成式人工智能技术用以在原始内容上进行精简并生成对应的表格

Part of the content in this article uses GenAI technology to streamline the original content and generate corresponding tables.

---

第一章：ACH 网络核心概念#

自动清算系统（Automated Clearing House, ACH）是美国金融体系的基石之一，一个庞大而高效的电子网络，专门用于处理大批量的贷记和借记交易 。对于任何希望了解 ACH 系统运作机制和原理的读者，本指南将从核心概念入手，逐步深入到技术细节，旨在提供一份全面的参考。

1.1 什么是 ACH？#

ACH 网络并非一个实时支付系统，而是一个基于 “存储转发”（store-and-forward）模式的批处理系统 。这意味着交易指令在一天中的特定时间点被收集、捆绑成批次，然后统一发送和处理，而不是逐笔即时完成。这种设计使其在处理海量、非紧急的支付时具有极高的效率和极低的成本。

该网络主要支持两种核心的交易类型，它们共同构成了其应用场景的广度 ：

• 直接存款 (Direct Deposit - ACH Credit): 这是一种 “推送” 资金的操作，即付款方主动将资金发送到收款方的银行账户中。最常见的应用场景包括企业发放员工工资、政府发放社会福利和养老金、税务退款以及公司支付股息和利息等 。ACH 贷记交易构成了美国薪资和福利发放的主要渠道。

• 直接付款 (Direct Payment - ACH Debit): 这是一种 “拉取” 资金的操作，即收款方根据预先授权，从付款方的银行账户中提取资金。其典型应用包括消费者授权的周期性账单支付（如抵押贷款、水电费、保险费）和各类订阅服务费的自动扣款 。

为了更清晰地定位 ACH，有必要将其与美国支付生态中的其他关键系统进行比较：

• 电汇 (Wire Transfer): ACH 主要服务于美国国内的支付，其交易成本通常远低于电汇。电汇（通过 Fedwire 系统）可以处理国际交易，费用更高，但其优势在于它是逐笔实时全额结算（Real-Time Gross Settlement, RTGS），资金几乎可以立即到账并被视为最终结算 。相比之下，ACH 的批处理模式决定了其结算存在一定的延迟。

• 实时支付 (RTP/FedNow): 近年来，美国推出了真正的 24/7/365 实时支付网络，如 The Clearing House 的 RTP® 和美联储的 FedNow® 服务。这些系统提供即时清算和结算。Nacha（ACH 网络的管理机构）将这些新兴的即时支付系统定位为对 ACH 的补充，而非替代品。两者服务于不同的应用场景：ACH 擅长处理计划内、大批量的周期性支付，而实时支付则更适用于需要即时性和最终性的高价值或紧急交易 。

1.2 ACH 网络的关键参与方#

ACH 网络的顺畅运行依赖于一个由多个角色组成的精密生态系统。每个参与方都承担着由 Nacha 规则明确定义的特定职责和法律义务，理解这些角色是掌握 ACH 运作逻辑的关键。

要在某人的银行账户上发起 ACH 贷记或借记，首先需要找到一家愿意代表你处理这些交易的银行。只有银行才被允许直接发起 ACH 交易。你需要在银行开立一个企业账户，并申请通过他们发起（originate—— 用于表示 “发送” 的技术术语）ACH 交易的权限。如果他们同意，他们就会成为你的 ODFI，该缩写代表 “Originating Depository Financial Institution”（发起存管金融机构），不过说白了这只是 “银行” 的一个花哨称呼。

• 发起方 (Originator): 这是整个交易流程的起点，可以是任何希望发起 ACH 支付的实体，包括个人、公司或政府机构 。发起方的核心责任是在发起任何借记或信用交易之前，必须从接收方那里获得清晰、可验证的授权 。

• 发起方存管金融机构 (Originating Depository Financial Institution - ODFI): 这是发起方的银行，必须是 Nacha 的成员。ODFI 扮演着网络 “守门人” 的角色。它接收来自其客户（发起方）的支付指令，将这些指令打包成符合 Nacha 规范的 ACH 文件，并将其提交给 ACH 运营商 。ODFI 向整个网络担保其提交的所有交易都经过了合法授权。这一角色使其承担了显著的承保和合规风险。在实际操作中，ODFI 往往在交易最终结算前就向发起方的账户垫付或扣除资金，从而承担了初始的信用风险 。

• ACH 运营商 (ACH Operator): 这是网络的中央清算设施，负责处理 ODFI 与 RDFI 之间的交易。美国有两个 ACH 运营商：美联储的 FedACH 和 The Clearing House 的电子支付网络 (EPN)。这两个运营商的系统是完全互通的，确保了网络的全覆盖 。它们从所有 ODFI 接收 ACH 文件批次，按目的地 RDFI 对海量分录进行分类，然后将整理好的文件分发给相应的 RDFI 。此外，运营商还负责计算其成员金融机构之间的净额结算头寸 。FedACH 同时处理政府和商业交易，而 EPN 作为一个私营运营商，主要处理商业交易量 。

• 接收方存管金融机构 (Receiving Depository Financial Institution - RDFI): 这是接收方的银行。它从 ACH 运营商处接收 ACH 文件，并根据文件中的指令，在生效日期（Effective Entry Date）将资金贷记或借记其客户（接收方）的账户 。RDFI 的主要职责是及时准确地处理入账交易，并负责发起任何必要的退款（Returns）操作。

• 接收方 (Receiver): 这是交易的最终对象，其银行账户被贷记或借记资金 。接收方的核心角色是向发起方提供交易授权。

• 第三方服务提供商 (Third-Party Service Providers - TPSP) 与第三方发送方 (Third-Party Senders - TPS): 在复杂的支付生态中，许多实体作为中介提供 ACH 处理服务。例如，一家薪资处理公司就是一个典型的 TPS，它会汇集来自多家企业（发起方）的薪资支付指令，然后通过自己与 ODFI 的单一合作关系，将这些交易提交到 ACH 网络中 。Nacha 制定了专门的规则来明确 TPS 的角色、责任和风险评估要求，甚至包括更复杂的 “嵌套 TPS”（Nested TPS）关系，即一个 TPS 通过另一个 TPS 进行处理 。

这种多方参与的结构带来了一个重要的非对称性特征，尤其是在风险和责任的分配上。ODFI 作为将交易引入网络的一方，承担了主要的担保责任。它们必须对自己的客户（发起方）进行严格的尽职调查和风险评估，因为一旦发起方出现欺诈或违规行为，ODFI 将面临直接的财务损失和合规处罚。对于希望发起 ACH 交易的企业或开发者而言，这意味着获得 ODFI 的服务并非易事，银行会对发起方的业务模式、财务状况和反欺诈能力进行全面审查。因此，ACH 的风险管理不仅是最佳实践，更是参与网络的先决条件，由承担主要风险的 ODFI 强制执行。

1.3 监管与规则：Nacha 的角色#

ACH 网络的稳定和可靠性离不开一个强大的治理框架，其核心便是 Nacha。

• Nacha 的角色: Nacha（前身为 National Automated Clearing House Association）是一个非营利性组织，负责管理和治理 ACH 网络 。需要明确的是，Nacha 并非一个联邦政府机构，但它与美联储、美国财政部及其他银行监管机构保持着密切的合作关系 。其最核心的职能是制定、管理和执行一套全面的运营规则，即 Nacha Operating Rules 。

• Nacha 运营规则: 这套规则是每一笔 ACH 支付的法律和操作基础，详细定义了网络中所有参与方的角色、责任和法律义务 。规则内容涵盖了从交易授权、数据安全、文件格式、结算流程到异常处理的方方面面。这套规则并非一成不变，而是通过一个正式、包容、协商一致的规则制定流程持续演进，以适应技术发展和市场需求的变化 。

• 规则的执行: Nacha 拥有一套正式的规则执行机制，通过警告、罚款和仲裁等手段来纠正违规行为，维护网络的整体质量和声誉 。参与的金融机构可以举报涉嫌违规的行为。对于情节严重的违规，例如故意或鲁莽的行为涉及大量交易或高额资金，Nacha 可以处以最高达 50 万美元的罚款，并指示 ODFI 暂停违规发起方的交易权限 。

---

第二章：ACH 交易的生命周期#

要真正理解 ACH，就必须掌握其交易从诞生到终结的完整流程。我们将详细拆解一笔标准 ACH 交易的各个环节，阐明其时间线和独特的结算确认机制。

2.1 交易流程详解：从发起到结算#

我们将以一个典型的 ACH 借记交易（例如，支付水电费）为例，来逐步追踪其生命周期 。需要说明的是，ACH 贷记交易的流程和时间线完全相同。

• 第零步：发起与授权 (Initiation & Authorization)
  这是在 ACH 交易开始前的步骤，不属于 ACH 交易处理时间线的一部分。但 ACH 交易始于发起方（在这里是 Acme, Inc.）从接收方（客户）处获得支付授权。这份授权必须清晰明确，并且发起方有责任妥善保管授权记录，以备核查 。

• 第一步：ODFI 文件提交 (ODFI File Submission)
  发起方根据授权信息，创建一个包含所有必要交易细节的 ACH 文件。这个文件随后被安全地传输到其合作的 ODFI，通常是通过一个安全的 FTP 服务器 。每个 ODFI 都有自己的每日文件接收截止时间（cut-off time），超过该时间的交易将被顺延至下一个工作日处理 。

• 第二步：ODFI 批处理与传输 (ODFI Batching & Transmission)
  ODFI 收到文件后，会将其与其他发起方的文件汇集、打包成更大的批次。在预定的处理时间点，ODFI 将这些批处理文件发送给一个 ACH 运营商（FedACH 或 EPN）。

• 第三步：ACH 运营商清算 (ACH Operator Clearing)
  ACH 运营商接收到来自各个 ODFI 的海量交易数据后，开始进行清算。它会根据每个分录中的目的地 RDFI 路由号码进行分类和排序，然后将属于同一个 RDFI 的所有交易打包成新的文件，准备分发 。同时，运营商会计算所有参与银行间的净结算头寸，即每家银行应付或应收的总金额 。

• 第四步：RDFI 处理 (RDFI Processing)
  RDFI 从 ACH 运营商处获取为其准备好的文件。在文件指定的 “生效日期”（Effective Entry Date），RDFI 会从接收方的账户中扣除（借记）相应的款项 。

• 第五步：结算 (Settlement)
  这是资金在金融机构间实际流转的最后一步。ODFI 和 RDFI 通过它们在美联储的储备金账户完成最终的资金划拨。这一步完成后，ODFI 才算真正收回了它可能在交易初期为发起方垫付的资金 。

实际上 ACH 文件的传递基本全程依赖 FTP 服务器，ACH 运营商会提供一个庞大的 FTP 服务器供 ODFI 和 RDFI 在上面塞各种各样的 ACH 文件。

2.2 ACH 贷记 (Credit) vs. ACH 借记 (Debit)#

尽管流程相似，但贷记和借记交易在资金流向和风险特征上有着本质的区别。

• 贷记交易 ("Push"): 在贷记交易中，发起方主动将资金 “推送” 到接收方的账户 。整个流程与上述借记交易基本一致，唯一的区别在于，在第五步 RDFI 处理时，是对接收方的账户进行贷记（存入资金）操作 。

• 借记交易 ("Pull"): 在借记交易中，发起方根据授权从接收方的账户中 “拉取” 资金 。

这两种交易类型的风险状况存在显著差异，这一点对于设计支付系统的开发者至关重要。ACH 借记交易的欺诈风险天然更高，因为它是从他人账户中取钱。未经授权的借记会直接导致受害者资金损失。因此，Nacha 规则对借记交易的授权要求极为严格，通常要求书面或 “类似认证” 的授权 。特别是针对消费者的借记交易，规则提供了长达 60 天的退款窗口期以保护消费者权益。这意味着，发起借记交易的企业必须建立非常强大的授权管理和身份验证流程来控制风险 。

相比之下，贷记交易的风险更多地集中在 “操作风险” 上，即确保资金被推送到正确的账户。一旦信用交易发送错误，想要追回资金（recall）会非常困难。近年来，“贷记推送欺诈” (credit-push fraud) 也日益增多，其手法是欺骗付款人主动授权将资金发送到欺诈者控制的账户 。

无论是 Push 还是 Pull，ACH 运营商收取的交易费用始终由 ODFI 支付。但所有参与方都需要向 ACH 运营商支付网络参与费用。

2.3 交易时间线与资金可用性#

ACH 的批处理特性决定了其独特的结算时间线和资金确认逻辑。

1. 标准 ACH (次日结算): 传统上，ACH 是一个次日结算系统。在一个工作日（Day 1）截止时间前提交的 ACH 文件，会在当晚由运营商处理，并在次日（Day 2）清晨送达 RDFI 进行结算 。

• “没消息就是好消息” 原则: 这是理解 ACH 结算的核心。ACH 网络本身不会为一笔成功的交易提供一个 “成功” 的确认回执。发起方只会在交易失败时（即被退款时）才会收到通知 。因此，在没有收到任何退款通知的情况下，交易被默认为成功。

• 实际资金可信时间: 正因为上述原则，发起方不能在借记交易结算的当天就认为资金已经 “安全” 或 “清算完毕”。RDFI 有权在一定期限内发起退款。对于大多数常规错误（如资金不足），退款窗口期通常是 2 个工作日。但对于消费者声称的未经授权的借记，退款窗口期长达 60 个日历日 。因此，行业内的普遍做法是，在借记交易结算后，至少等待 3-4 个工作日，待最常见的退款窗口期过后，才将这笔资金视为可靠和可用的。

2. 当日 ACH (Same Day ACH):

• 功能: 为了满足市场对更快支付的需求，Nacha 推出了当日 ACH 规则。它允许发起方在提交 ACH 文件的当天就完成资金的结算。发起方通过将 ACH 文件中的 “生效日期” 字段设置为当前工作日来请求当日处理 。

• 处理窗口: ACH 运营商在每个工作日提供多个当日 ACH 的处理窗口，最早的批次可以在几小时内完成结算 。

• 限制: 当日 ACH 并非没有限制。它不适用于国际交易（IAT），同时每笔交易有 100 万美元的上限，并且不允许通过拆分一笔较大交易为多笔较小的交易来规避这一点。此外，ODFI 可能会对当日 ACH 交易收取比标准 ACH 更高的费用（某些情况下高达标准 ACH 的 100 倍）。

理解当日 ACH 的一个关键点是，它加速的是资金的结算速度，但并不改变风险确认的时间。当日 ACH 缩短了从发起方到接收方账户的资金流转时间（即生命周期的前三个步骤），但它并没有缩短 RDFI 发起退款的法定时限（即生命周期的后两个步骤）。RDFI 仍然拥有与标准 ACH 相同的退款窗口期（例如，对于 R01 仍为 2 个工作日，对于 R10 仍为 60 个日历日）。这意味着，即使一笔当日 ACH 借记的资金在当天就到达了发起方的账户，这笔资金在本质上仍然是 “有风险的”，随时可能在未来的几天甚至几周内被撤回。因此，当日 ACH 是一个提升现金流效率的强大工具，但它不能被误解为一种降低结算风险的机制。在设计系统逻辑时，必须清晰地认识到这一点，避免将当日到账的资金错误地处理为最终已清算的资金。

2.4 交易示例#

为了让你更容易理解整个过程发生了什么，以及对应的时间点，让我们现在扮演一家名为 Acme, Inc. 的水电公司。该公司的合作银行是 Expel Bank，他们和 Acme, Inc. 关系良好，允许我们直接使用 ACH 文件来处理付款。

• 第一天 19:00 / 07:00AM | 发起方 -> ODFI（我们的银行）
  取决于客户和银行达成的协议，银行会要求客户在某个时间点之前提交 ACH 文件以供他们处理。在这个故事里，Expel Bank 要求 Acme, Inc. 在每天晚上 7 点前提交 ACH 文件。一到晚上 7 点截止时刻，Expel Bank 会验证 Acme, Inc. 的 ACH 文件是否通过一系列基本合理性检查（例如账户号码是否合理、金额是否未超过某些核保阈值等）。他们还会采取措施确认文件确实来自我们，而不是有人冒充我们。

• 第二天 00:01 / 12:01AM | ODFI -> 美联储 -> RDFI（收款方银行）
  一旦 Expel Bank 认定我们的 ACH 文件合格，他们就会将该 ACH 文件转交给美联储进行处理。由于当日 ACH 的费用比标准 ACH 更高，作为一家在全美 50 个州运营的超级公司，我们要尽可能地为股东节省成本，因此我们选择使用标准 ACH（次日 ACH）。这意味着发送至美联储的 ACH 借记请求会在午夜前后处理，并在差不多同一时间提供给 RDFI（收款方银行）。

• 第二天 05:00 / 05:00AM | RDFI -> 收款人
  收款行会在早上开门营业时（为简单起见，假设是凌晨 5 点）获取该借记通知，并在那时从其客户的账户中扣减资金。

  如你所见，对于未被退回的 ACH 转账，时间安排相当简单：在晚上 7 点之前发起的 ACH 文件会在次日早晨结算。

  当 ACH 文件被退回时，处理时间就会变长。

• 第四天 00:01 / 12:01AM RDFI -> 美联储 -> ODFI
  哎呀，我们的客户由于美国历史上最伟大的特会赢总统颁布的行政令而失去了工作，客户现在陷入了经济危机，无法支付我们的账单。
  当 RDFI 在第 2 天开始时收到 ACH 借记的通知，他们被允许最迟到下一个营业日结束前告知美联储他们想要退回该 ACH 借记。有时，银行动作很快，会在同日结束前通知美联储。然而大多数情况下，银行会尽可能晚地通知美联储，也就是在第 3 天结束时。

  一旦美联储收到退回，他们会在当晚通知 ODFI 该 ACH 借记已被退回。

  对于次日截止期限有一个显著的例外：如果客户通知银行他们并未授权该 ACH 借记（例如，欺诈者使用被盗的银行账户），RDFI 被允许在 60 天内退回该 ACH 借记。正因如此，ACH 协议对消费者非常友好，因为 ACH 借记的发起方现在必须归还其扣取的资金，并设法取回因该笔借记而提供的任何对价。

• 第四天 05:00 / 05:00AM | ODFI -> 发起方
  ODFI 银行会在早上开始营业时的某个时间（为简单起见，仍以早上 5 点为例）收到这份退回通知，并将其转发给发起方。

  需要注意的是，ACH 系统从不会对一笔 ACH 借记已成功通过提供正向确认。ACH 发起方可能收到的唯一响应是通知其有一笔退回。由于这种 “没有消息就是好消息” 的做法，ACH 借记的发起方谨慎起见应再等待额外 3 个工作日都 “没有消息” 后，才将产品发货给客户。尽管 ACH 系统被称为次日清算系统，但在实践中因为这个原因并非如此。

  因此，例如，企业在周一提交的一笔 ACH 借记，一般要到周四早上才能认为资金已无问题。周三提交的 ACH 借记，要到周一早上才应视为稳妥。

让我们用一个简单的表格来描述这个时间线

如果我们想要更快地收到付款而选用当日 ACH 会怎样？

现在，上述表格中的第二步和第三步可以在第一天更早的时间发生。ODFI 将 ACH 请求转发给 Fed（以及 RDFI）以及 RDFI 结算资金，现在都有了新的时间窗口。

• 窗口 1： 美联储在太平洋时间上午 7:30 之前收到 ACH 请求，RDFI 在太平洋时间上午 10 点前完成资金结算
• 窗口 2： 美联储在太平洋时间上午 11:45 之前收到 ACH 请求，RDFI 在太平洋时间下午 2 点前完成资金结算
• 窗口 3：美联储在太平洋时间下午 1:45 之前收到 ACH 请求，RDFI 在太平洋时间下午 3:00 前完成资金结算。

此外，新的规则还要求 RDFI 必须在其当地时间下午 5 点前使资金对收款人可用。

现在，我们将在工作时间的一早提交 ACH 文件，并使用当日 ACH，于是时间线变为了这样

---

第三章：技术核心：NACHA 文件格式#

对于需要在技术层面与 ACH 网络交互的开发者来说，理解其文件格式是不可或不可缺的一环。本章将深入剖析 NACHA 文件的结构和具体字段，为文件生成和解析提供一份详尽的蓝图。

3.1 文件结构总览#

所有 ACH 交易都是通过一个严格定义的文本文件来承载的。

• 格式: ACH 文件是一种固定宽度的 ASCII 文本文件。文件中的每一行，被称为一个 “记录”（Record），其长度严格固定为 94 个字符 。任何偏差都将导致文件被拒绝。

• 结构: 文件采用一种分层、嵌套的结构，可以形象地理解为 “信封套信封”：

  • 文件 (File): 最外层的信封，由一个文件头记录（File Header Record）开始，一个文件控制记录（File Control Record）结束。一个文件可以包含一个或多个批次。

  • 批次 (Batch): 内层的信封，由一个批次头记录（Batch Header Record）开始，一个批次控制记录（Batch Control Record）结束。一个批次包含一组具有相同特征（如发起公司、SEC 码、生效日期）的交易。

  • 分录 (Entry): 最核心的内容，即单笔交易。由一个分录详细记录（Entry Detail Record）表示，后面可以跟随一个或多个可选的附录记录（Addenda Record）。

• 补位规则 (Padding Rules): 这是文件生成时一个极易出错的细节。所有字段必须严格按照其定义的数据类型和长度进行补位 。

  • 数字字段 (Numeric Fields): 必须右对齐，并在左边用前导零（0）补足长度。例如，一个长度为 10 的金额字段，数值 12345 应表示为 0000012345。

  • 字母数字字段 (Alphanumeric Fields): 必须左对齐，并在右边用空格补足长度。例如，一个长度为 16 的公司名称字段，MYCOMPANY 应表示为 MYCOMPANY       。

• 分块因数 (Blocking Factor): 这是一个历史遗留的规范。ACH 文件被组织成 “块”（Blocks），每块包含 10 条记录。如果一个文件的总记录数不是 10 的倍数，文件末尾需要填充若干行纯 9（94 个 9）的记录，直到总行数能被 10 整除为止

3.2 记录类型详解#

ACH 文件由五种必需记录类型和一种可选记录类型组成。下表提供了对这些记录及其关键字段的详细解析，这是任何需要生成 NACHA 文件的开发者的核心参考资料。

文件头记录 (File Header Record) - 记录类型 '1'

• 用途: 作为文件的第一条记录，它提供了关于整个文件的元数据，标识了文件的来源和目的地。

公司 / 批次头记录 (Company/Batch Header Record) - 记录类型 '5'

• 用途: 标志一个新批次的开始，定义了该批次内所有分录的共同属性。

分录详细记录 (Entry Detail Record) - 记录类型 '6'

• 用途: 文件的核心，代表一笔具体的交易。每个支付对应一条分录详细记录。

分录详细附录记录 (Entry Detail Addenda Record) - 记录类型 '7' (可选)

• 用途: 为紧邻其前的分录详细记录提供补充信息 。在企业对企业（B2B）支付中（如 CTX 类型的交易），它被广泛用于传输汇款信息，如发票号码、金额等。一个分录可以跟随多达 9,999 条附录记录。

公司 / 批次控制记录 (Company/Batch Control Record) - 记录类型 '8'

• 用途: 作为批次的 “页脚”，包含校验和，以确保批次数据的完整性和准确性。

文件控制记录 (File Control Record) - 记录类型 '9'

• 用途: 文件的最后一条记录，包含对整个文件内容的校验和。

---

第四章：分类与授权：标准分录类别 (SEC) 码#

在 ACH 的世界里，并非所有交易都生而平等。标准分录类别（Standard Entry Class, SEC）码是一个三字母的代码，它像一个标签，精确地定义了一笔交易的 “血统” 和它应遵循的 “法律”。对于发起方而言，选择正确的 SEC 码是其核心责任之一，因为它直接决定了授权要求、适用规则以及最重要的 —— 风险敞口。

4.1 SEC 码的用途与重要性#

SEC 码必须在每个批次的头记录（Batch Header Record）中指定 。它的主要作用是告知 RDFI，这笔交易是如何获得接收方授权的 。例如，它是通过互联网授权的（WEB），还是通过电话授权的（TEL），抑或是企业间的协议授权（CCD）。

这个选择绝非技术上的细枝末节，它具有深远的业务和法律影响。不同的 SEC 码对应着 Nacha 规则中不同的条款，尤其是在处理未经授权交易的退款时限方面 。错误地使用 SEC 码，比如将一笔企业间交易标记为消费者交易，可能会导致发起方承担本不应承担的巨大风险。

这种机制可以被视为一种内置的风险管理开关。例如，Nacha 规则为消费者提供了强有力的保护，允许他们在发现未经授权的借记交易后有 60 天的时间提出异议（使用 PPD 或 WEB 码）。然而，对于企业间的交易（使用 CCD 码），这个窗口期被大幅缩短至 2 个工作日 。这种差异反映了两种场景下信息对称性和商业惯例的不同。如果一个发起方在向另一个企业收款时，错误地使用了 PPD 码，它就无意中赋予了其商业对手方以消费者的权利，将自身的风险暴露期从短短两天延长到了两个月。因此，任何一个设计良好的 ACH 支付系统，都必须根据交易对手方的性质（消费者或企业）和授权方式，来强制执行正确的 SEC 码选择，而不是将其作为一个可以随意填写的选项。

4.2 常用 SEC 码详解#

虽然 Nacha 定义了多种 SEC 码，但在实际应用中，绝大多数交易都集中在少数几个核心代码上。下表总结了最常见的 SEC 码及其关键属性，是设计支付流程时的重要决策依据。

• PPD (Prearranged Payment and Deposit): 这是最传统的 SEC 码之一，适用于发起方与消费者之间存在长期、稳定支付关系的场景 。其核心是基于一份预先存在的、由消费者书面签署或通过其他可靠方式认证的授权文件。

• CCD (Corporate Credit or Debit): 这是 B2B 交易的专用代码。它假定交易双方都是商业实体，并且已经就 ACH 支付条款达成了一份商业协议（Trading Partner Agreement）。这种商业对商业的背景是其退款窗口期远短于消费者交易的根本原因。

• WEB (Internet-Initiated/Mobile Entry): 随着电子商务的兴起，WEB 码已成为最常见的 SEC 码之一。它专门用于处理消费者在网站或移动应用上授权的借记交易 。Nacha 对 WEB 交易的授权流程有额外的安全要求，发起方必须采用 “商业上合理” 的欺诈检测系统，并对用户的身份进行验证。

• TEL (Telephone-Initiated Entry): 此代码适用于通过电话完成的销售或收款。由于授权并非书面形式，Nacha 规则要求发起方必须对授权通话进行录音，或者在交易发生前向消费者发送一份书面确认函 。

• ARC (Accounts Receivable Entry): 该代码为处理应收账款提供了一种高效的方式，允许收款人将收到的纸质支票（非企业支票）直接在后台转换为一笔 ACH 借记，而无需将支票存入银行。使用的前提是必须已向付款人明确告知了这种可能性 。

---

第五章：异常处理：退款与变更通知#

一个稳健的支付系统不仅要能处理成功的交易，更要能优雅地应对各种异常情况。在 ACH 网络中，异常处理主要通过两种机制实现：退款（Returns）和变更通知（Notifications of Change, NOC）。

5.1 ACH 退款 (Returns) 流程#

当一笔 ACH 交易因故无法完成时，就会产生一笔退款。ACH 退款本身也是一笔 ACH 交易，由 RDFI（在极少数情况下由 ODFI 或 ACH 运营商）创建，目的是将原始交易的资金原路退回 。

退款的生命周期如下：

• 触发: RDFI 收到一笔无法处理的 ACH 分录（例如，目标账户已关闭），或者其客户（接收方）通知银行某笔交易未经授权。

• 创建与发送: RDFI 根据失败的具体原因，选择一个标准的退款原因代码（Return Reason Code），并创建一笔退款分录。这笔退款必须在 Nacha 规则为该代码规定的时限内发送给 ACH 运营商 。

• 路由: ACH 运营商将这笔退款分录路由回最初的 ODFI。

• 通知与记账: ODFI 收到退款通知后，会从发起方的账户中扣回相应资金，并将退款的详细信息（包括原因代码）提供给发起方 。

5.2 常见退款原因代码 (Return Reason Codes)#

每个退款都附有一个以 'R' 开头的两位数代码，用以解释退款的原因。理解这些代码对于发起方诊断问题、联系客户并采取正确措施至关重要。

5.3 变更通知 (Notification of Change - NOC)#

变更通知（NOC）是一种非资金性的 ACH 交易，是 ACH 网络内置的一种主动纠错机制。当 RDFI 收到一笔交易，发现其中的某些信息（如账号、交易代码）不完全正确，但仍能成功处理该交易时，它会向 ODFI 发送一个 NOC 。

• 用途: NOC 的目的是通知发起方更正其记录，以确保未来的交易能够顺利进行。例如，客户的账户从支票账户变更为储蓄账户，或者银行系统升级导致账号发生微小变化。原始的支付交易会正常结算。

• 处理: 根据 Nacha 规则，发起方在收到 NOC 后，有义务在 6 个银行工作日内，或在发起下一笔到该接收方的交易之前（以较晚者为准），更新其系统中的记录。

---

第六章：风险管理与合规#

使用 ACH 网络不仅仅是技术集成，更是一项严肃的商业活动，需要严格的风险管理和合规实践。Nacha 和 ODFI 对所有网络参与者，特别是发起方，都设定了明确的期望和要求。

6.1 核心风险领域#

参与 ACH 交易的企业面临四种主要风险：

• 信用风险 (Credit Risk): 主要体现在两个方面。一是 ODFI 对发起方的信用风险，即 ODFI 在未收到最终结算资金前为发起方垫款的风险。二是发起方的信用风险，即在发出商品或提供服务后，收到的 ACH 借记款项被退回。

• 操作风险 (Operational Risk): 指因内部流程不完善、人为错误或系统故障导致的损失。例如，生成格式错误的 ACH 文件、未能及时处理 NOC 导致后续交易失败、或错误处理退款等。

• 欺诈风险 (Fraud Risk): 来自内外部的恶意行为。最典型的是未经授权的借记交易，即从他人账户中非法扣款。此外，贷记推送欺诈也是一个日益严峻的挑战 。

• 合规风险 (Compliance Risk): 指因未能遵守 Nacha 运营规则而面临罚款、赔偿责任甚至被暂停或终止网络接入资格的风险 。

6.2 Nacha 合规要求#

为了管理这些风险，Nacha 规定了一系列所有发起方必须遵守的核心要求：

• 授权管理: 发起方必须为每一笔交易获得接收方的有效授权，并且必须将授权证明自授权终止之日起保留两年 。这是 ACH 合规的基石。

• 数据安全: 必须保护所有敏感的金融数据（如银行账号、路由号码）在传输和存储过程中的安全。严禁通过不加密的方式（如普通电子邮件）传输这些信息 。

• 身份验证与欺诈检测: 发起方必须采用 “商业上合理”（commercially reasonable）的方法来验证客户身份并检测欺诈性交易 。具体措施可以包括小额存款验证（micro-deposits）、使用第三方身份验证服务、或监控异常交易模式等 。Nacha 规则也在不断更新，要求金融机构加强对贷记推送欺诈的监控 。

• 退款率阈值监控: Nacha 极其重视对退款率的监控，并将其视为衡量发起方操作质量和风险水平的关键指标。发起方必须将其各类退款率控制在规定的阈值以下，否则将面临 ODFI 和 Nacha 的审查 。

• 整体借记退款率 (Overall Debit Return Rate): 必须低于 15%。

• 管理性退款率 (Administrative Return Rate): 针对 R02, R03, R04 的退款，必须低于 3%。

• 未经授权退款率 (Unauthorized Return Rate): 针对 R05, R07, R10, R11, R29 等的退款，必须低于 0.5%。

这些阈值并非随意设定。高的管理性退款率（超过 3%）通常表明发起方的数据质量控制不佳或操作流程存在问题（例如，没有及时根据 NOC 更新信息）。而高的未经授权退款率（超过 0.5%）则是一个强烈的危险信号，可能预示着欺诈活动或糟糕的授权实践。因此，对于构建 ACH 系统的企业和开发者来说，建立一个能够实时监控并报告这些关键退款率的仪表盘，不是一个可选功能，而是一个核心的合规与风险控制模块。