Automated Clearing House (ACH) is the dominant low-value transfer mechanism in the US. ACH typically refers to the Federal Reserve’s FedACH network which implements the rules maintained by Nacha (formerly stylized as the National Automated Clearing House Association, NACHA). Electronic Payment Network (EPN) is an alternative ACH network operated by The Clearing House (TCH).

ACH is an asynchronous network; files containing batches of transfers are sent from originating financial institutions to the Federal Reserve which re-batches the files for onward transmission to receiving financial institutions. FedACH settles within the financial institutions’ Federal Reserve accounts.

ACH supports both credit and debit origination; you can pull and push money. The timeframes have been shortening in the last ten years. FedACH now operates three same-day windows. FedACH also operates six non same-day windows.

An ACH transfer includes mandatory details of the account number, routing number, and amount. There are optional parameters of the recipient’s name and identifying number. Explicitly, most financial institutions don’t enforce that the recipient name on the transfer matches the account holder name.


Before you originate an ACH debit, you need to collect an authorization from the person you’re debiting. The goal is to make sure funds aren’t being pulled out of a customer’s account without their consent (makes sense!).

Depending on your use case and who you’re debiting you’ll need to meet different requirements when collecting your authorization.

If you’re debiting a business, the process is fairly straightforward. You need to obtain legally enforceable authorization. Most likely, this looks like including a clear description of the expected debits (both amounts and timing) in your terms of service. You’ll also set the Standard Entry Class (SEC) code to Corporate Credit or Debit (CCD).

If you’re debiting a consumer, the requirements are more nuanced.

There are three types of authorizations for consumer debits: one time, recurring, and standing authorization.

The most straightforward is a one time debit which Nacha calls a Single Entry [0]. A Single Entry is exactly as it sounds: a one time debit for a specified amount.

The second is for Recurring Entries. These are always for the same amount (or within a communicated range of amounts) at a predictable time. This your rent payment for $2,500 on the first of every month. If you ever need to change the amount or the timing, you’ll need to give your customer 10 days notice [1].

If you’re planning to debit at variable times or for variable amounts, you’ll need a Standing Authorization but you’ll also need to ensure affirmative action for each Subsequent Entry. A Standing Authorization has to include specifics on which actions the consumer might take to trigger Subsequent Entries. For example, if you own an acupuncture practice, your patient might agree to be debited each time they come in for an appointment. The debit is triggered by an action on the consumers part.

Regardless of the type, all consumer authorizations must include:

(a) Language regarding whether the authorization is for a Single Entry, Recurring Entries, or one or more Subsequent Entries initiated under the terms of a Standing Authorization;

(b) The amount, or logic for how the amount will be determined;

(c) The timing (including the start date), number, and/or frequency of the Entries;

(d) The name or identity of the person being debited;

(e) The account to be debited;

(f) The date of the authorization; and

(g) Language on how to revoke the authorization (including the time and manner in which the communication must occur).

The authorization must be obtained in writing [2]. The user needs to affirmatively agree to the authorization. A signature always works, but other generally acceptable forms of electronic consent can work as well. The definitive requirements are those laid out in the Electronic Signatures in Global and National Commerce Act. It hopefully goes without saying, but you should always rely on the advice of counsel when determining whether your consumer flow meets the requirements here.

In addition to holding on to the authorization yourself, you’ll also need to give a copy to the receiver.


ACH transfers can be returned. Common return reasons are that the account number isn’t recognized, the account has insufficient funds, and that the account holder states the transfer is unauthorized. Transfer returns can roughly be divided into administrative return (the account number isn't recognized, for example) and unauthorized returns (the account holder stated the transfer wasn’t authorized). Nacha mandates that [administrative returns must be limited to 15% and unauthorized returns must be limited to 0.5%. Both are calculated on monthly count.

Returns can be correlated with originating transfers by using the date, amount, account number, routing number, and the trace number. Trace numbers are 15 digits but with only seven digits of entropy (as the leading eight identify the original financial institution). Trace numbers need to be unique in a Nacha file and monotonically increase. For any reasonably large institution, it’s usually not possible to uniquely rely on trace numbers for reconciling returns.

Most ACH debits are typically able to be returned within 2 days for debits from commercial accounts [3] and 60 days for debits from consumer accounts [4]. Despite these windows, exceptions are made for claims that an ACH debit was unauthorized. In these situations, the receiving bank will ask for an exception to process a late return. The originating bank must provide the proof of authorization or the late return request will be allowed.

If you have a debit returned after the typical window, you’ll see a proof of authorization request appear in your dashboard. The originating bank has 10 banking days to respond from the time they receive the request [5].

Alternatively, you can choose to accept the return and won’t need to provide the proof of authorization.


Explicitly, FedACH doesn’t intermediate disputes. This is different to the card networks. A transfer recipient can state a transfer is unauthorized and the receiving bank will return it. For corporate accounts this period is two business days. For consumer accounts, this is sixty days. Nacha recommends using non-ACH related dispute resolution mechanisms like contacting the account holder, collections agencies, or courts.

To reduce unauthorized returns, Nacha recommends (and in some cases requires) validation of account and routing number details.

Account validations

To validate account details you have two options:

  • Use a service like Plaid or Finicity, where an account holder provides their bank login details and the platform ~synchronously scrapes the bank’s website.
  • Send the account holder micro-deposits and have them confirm the amounts.

There are older methods like collecting an image of a voided check or using confirmation notes but they’re less used in modern integrations.

Reversals and other conventions

Nacha also has a number of conventions that have reached varying degrees of codification. One is reversals — reclaiming funds from an erroneous transfer. For reversals, Nacha requires all fields are the same except for the company_entry_description which must be REVERSAL, and the amount in the reverse direction. Importantly, reversals aren’t a network primitive; they’re regular transfers and therefore can be returned.

Other Nacha conventions with varying degrees of formality are child support payments, tax payments, and corporate trade exchange data.

Non-financial messages

ACH supports some non-financial messages. One is the confirmation note used for accounting and routing number validation. Another is a Notification of Change. Notifications of Change are optionally sent by receiving depository institutions to communicate that although a transfer has been accepted, in the future, updated details should be used.


The Federal Reserve’s FedACH schedule is here:

The Transmission Deadline is when FedACH must receive files. The Target Distribution is when FedACH aims to tell receiving depository institutions about the transfers. The Settlement Schedule is when FedACH will fund to the financial institutions’ Federal Reserve accounts.

Increase submits for every window and we can accept transfers up to an hour before the cut-offs.

Technical implementation

Nacha’s message format is a fixed-width flat file containing batches of transfer entries. Nacha’s specification is here:

Many financial institutions implement ACH by allowing clients to submit Nacha’s file format through SFTP servers. Submission to the Federal Reserve runs similarly but uses an IBM product, Connect:Direct. FedACH responds with a custom-formatted acknowledgement file within 15 minutes. (There are escalation channels if a file hasn’t been acknowledged in that timeframe.) Most financial institutions similarly operate an acknowledgement mechanism.

Operating an ACH integration

A common frustration with ACH is that there’s no transfer receipt notification method. As a transfer originator, you have no way to definitely know if or when a transfer has arrived to a recipient’s account.

Some depository institutions allow account holders to maintain an allowlist of companies that can debit their account. This is done by referencing the Company ID. In particular, if you’ll be debiting businesses, you’ll likely want them to register your Company ID with their financial institution.

ACH transfers have many structured parameters like the company_name, company_discretionary_data, individual_name, and individual_id. The specifics of how these are serialized to a transaction description shown to a recipient vary by bank.

Typical operational issues you’ll run into are that Nacha’s file form is ASCII. If you’re allowing UTF-8 data submission you’ll want to flatten it. You’ll also want to exclude client entered data containing things like newline characters.

Not all financial institutions preserve the trace numbers you submit. You’ll want to understand if yours does as it makes a difference to how you’ll correlate returns.

Many financial institutions will fund your ACH transactions by aggregating your daily files and batches possible by transfer effective date. Understanding your bank’s aggregation method is necessary for you to reconcile the transfer instructions you’ve submitted to the cash in your bank account.

While not common, there are data quality issues with FedACH. In particular, the network itself doesn’t store the state of a transfer. Therefore it’s possible for a receiving depository institution to return a transfer multiple times, for example. It’s also possible for them to include the incorrect details on a return.


[0] NACHA Operating Rules Subsection Debit Entries to Consumer Accounts

[1] NACHA Operating Rules Subsection Notices of Variable Recurring Debit Entries to Consumer Accounts

[2] There are guidelines around oral authorizations but we don’t recommend these since they are hard to prove. Feel free to reach out to us if that’s something you’d like to discuss!

[3] NACHA Operating Guidelines, Section II, Chapter 26 Returns of Unauthorized/Improper Corporate Debits

[4] NACHA Operating Guidelines, Section II, Chapter 26 Returns of Unauthorized/Improper/Incomplete Consumer Debit Entries

[5] NACHA Operating Rules Subsection Retention and Provision of the Record of Authorization