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 系統的企業和開發者來說，建立一個能夠實時監控並報告這些關鍵退款率的儀表盤，不是一個可選功能，而是一個核心的合規與風險控制模塊。