flowchart LR
O[Originator] --> ODFI[ODFI<br/>Originator's Bank]
ODFI --> OP[ACH Operator<br/>Fed or EPN]
OP --> RDFI[RDFI<br/>Receiver's Bank]
RDFI --> R[Receiver]
ACH Processing Internals
Prerequisite: Payment Rails
Your payroll platform originates 50,000 ACH credits on Friday afternoon. Monday morning, 347 of them come back as R01 (Insufficient Funds) — except these are credits, not debits. You sent money to accounts that cannot receive it: closed accounts, invalid routing numbers, frozen accounts flagged by OFAC. The money left your funding account on Friday. The returns arrive two business days later. For 48 hours, your ledger showed 347 successful payments that were not successful, and your customer support team told employees their paychecks were deposited.
ACH is a batch settlement network. There is no real-time confirmation. There is no synchronous response that tells you whether the payment succeeded. You submit a file, the file processes overnight, and you find out what failed the next business day — or, for unauthorized debits, up to 60 calendar days later.
The NACHA File Format
Every ACH transaction moves through the network as a fixed-width text file. The format has not fundamentally changed since the 1970s. Each record is exactly 94 characters, no delimiters, no XML, no JSON. Field positions are defined by character offset.
A NACHA file is a hierarchy of six record types:
| Record | Type code | Count per file | Purpose |
|---|---|---|---|
| File Header | 1 | Exactly 1 | Identifies the originator and the file creation date |
| Batch Header | 5 | 1 per batch | Groups entries by SEC code, company, and effective date |
| Entry Detail | 6 | 1 per transaction | The individual credit or debit instruction |
| Addenda | 7 | 0–9,999 per entry | Supplemental data (payment remittance, return reason) |
| Batch Control | 8 | 1 per batch | Hash totals and entry counts for the batch |
| File Control | 9 | Exactly 1 | Hash totals and entry counts for the entire file |
An Entry Detail record contains the routing number, account number, amount, and individual identification of the receiver. The amount field is 10 characters, right-justified, zero-filled, in cents — 0000012500 represents $125.00.
6272610726181234567890 0000012500R38472615 John Smith 0011000015432167
| || | | | | | |
| |Routing |Account |Amount |Individual ID |Name | Trace
| |Number |Number |(cents) | | |Number
|Transaction Code |ODFI ID
|Record Type (6)Transaction codes encode both the account type and direction. 22 is a demand deposit (checking) credit. 27 is a checking debit. 32 is a savings credit. 37 is a savings debit. The two-digit code determines how the receiving bank applies the entry.
The Batch Control record contains an entry hash — the sum of all routing numbers in the batch, modulo 10^10. This is not a cryptographic hash. It is a checksum that detects transposition errors and missing entries during transmission. The File Control record sums the batch-level hashes and counts.
NACHA files have no encryption, no digital signatures, and no authentication at the file level. Security depends entirely on the transport layer — SFTP with mutual TLS, VPN tunnels, or the Federal Reserve’s FedLine Direct connection. A NACHA file intercepted in transit is a plaintext list of bank account numbers and routing numbers.
Origination Flow
ACH transactions flow through a five-party chain: Originator → ODFI → ACH Operator → RDFI → Receiver.
The Originator (your company) creates the NACHA file and submits it to the ODFI (Originating Depository Financial Institution — your bank). The ODFI validates the file format, checks that you have origination authority, and forwards it to one of two ACH Operators: the Federal Reserve (FedACH) or The Clearing House (EPN). The operator sorts entries by RDFI routing number and delivers them to the receiving banks. The RDFI posts the entries to receiver accounts.
Two ACH operators process all US ACH volume. FedACH handles approximately 60% of transactions. EPN handles the other 40%. Both operators interoperate — an entry submitted through FedACH can reach an RDFI that connects through EPN, and vice versa. The operators exchange entries through interoperator settlement.
Your NACHA file reaches the ACH operator through one of two channels. FedLine Direct is the Federal Reserve’s dedicated connection — high-volume originators connect directly. Most fintechs connect through their bank’s own submission portal, API, or SFTP endpoint. The bank batches your entries with entries from its other customers and submits a consolidated file to the operator.
Settlement Windows
ACH is not continuous. It operates on processing windows aligned to Eastern Time.
Next-day ACH settles in four windows:
| Window | Submission deadline | Settlement time | Volume |
|---|---|---|---|
| Night | 10:00 PM ET | 8:30 AM ET next day | ~35% of volume |
| Early morning | 2:15 AM ET | 8:30 AM ET same day | ~25% of volume |
| Morning | 6:00 AM ET | 1:00 PM ET same day | ~25% of volume |
| Afternoon | 11:00 AM ET | 5:00 PM ET same day | ~15% of volume |
Settlement means the Federal Reserve debits the ODFI’s master account and credits the RDFI’s master account. The interbank obligation is discharged at that point. Whether the RDFI posts the credit to the receiver’s account before or after settlement is up to the RDFI — many banks make funds available at 8:30 AM even for entries settling at 5:00 PM.
Same-Day ACH processes in three windows:
| Window | Submission deadline | Settlement time |
|---|---|---|
| Morning | 10:30 AM ET | 1:00 PM ET |
| Afternoon | 2:45 PM ET | 5:00 PM ET |
| Evening | 4:45 PM ET | 6:00 PM ET* |
*The evening window was added in 2024 to extend the Same-Day ACH processing day. Individual transactions are capped at $1,000,000. The ODFI pays a Same-Day ACH fee of $0.028 per entry to the ACH operator — a cost most originators pass through or absorb depending on volume.
Same-Day ACH volume has grown from 80 million transactions in 2018 to over 800 million in 2023. It is not real-time — the fastest path still takes 2–3 hours from submission to settlement. But it compresses next-day ACH’s overnight delay into the same business day.
Return Codes
When an RDFI cannot or will not post an entry, it returns it with a reason code. Returns are themselves NACHA file entries — the RDFI creates a return entry with an addenda record containing the return reason code and original trace number.
Common return codes:
| Code | Reason | Return window |
|---|---|---|
| R01 | Insufficient Funds | 2 business days |
| R02 | Account Closed | 2 business days |
| R03 | No Account / Unable to Locate | 2 business days |
| R04 | Invalid Account Number | 2 business days |
| R08 | Payment Stopped | 2 business days |
| R10 | Customer Advises Not Authorized | 60 calendar days |
| R11 | Customer Advises Entry Not in Accordance | 60 calendar days |
| R29 | Corporate Customer Advises Not Authorized | 2 business days |
The 60-day return window on R10 and R11 is the core risk of ACH debits. A consumer can dispute an ACH debit as unauthorized up to 60 calendar days after settlement. The money has already left the RDFI and settled to the ODFI. The return reverses the settlement — the ODFI’s master account is debited, and the ODFI passes that loss to the originator.
ACH debits carry asymmetric risk. You pull money from a customer’s account, settle it, spend it, and 58 days later the customer claims they never authorized the transaction. The funds reverse. Your exposure window on a single ACH debit is 60 calendar days of settled funds that can be clawed back.
The return rate is a critical metric. NACHA monitors originators’ return rates and enforces thresholds. An overall return rate above 15% or an unauthorized return rate (R10/R11) above 0.5% triggers NACHA enforcement — fines, enhanced monitoring, or termination of origination privileges.
SEC Codes
Every ACH batch carries a Standard Entry Class (SEC) code that identifies the authorization method. The SEC code determines which return codes apply, what documentation the originator must retain, and how long the consumer has to dispute.
| SEC Code | Name | Authorization | Use case |
|---|---|---|---|
| PPD | Prearranged Payment and Deposit | Written or electronic authorization on file | Payroll, recurring bill pay |
| CCD | Corporate Credit or Debit | Written agreement between businesses | B2B payments |
| WEB | Internet-Initiated Entry | Online authorization via website | E-commerce debits, online bill pay |
| TEL | Telephone-Initiated Entry | Recorded or written confirmation | Phone-authorized payments |
| IAT | International ACH Transaction | Per-transaction authorization | Cross-border ACH |
The SEC code is not cosmetic. A PPD debit requires the originator to retain a signed authorization form. A WEB debit requires the originator to use a commercially reasonable method of authentication. If a consumer disputes a WEB debit and the originator cannot produce evidence of online authorization, the return is upheld regardless of whether the payment was legitimate.
IAT entries carry additional addenda records with originator and receiver address information, required under the Bank Secrecy Act for cross-border transactions. An IAT entry has 7 mandatory addenda records versus 0 for a domestic PPD entry. Parsing IAT entries requires handling a different record layout than domestic entries.
NOC: Notification of Change
When an RDFI can post an entry but the account details are slightly wrong — a routing number changed due to a bank merger, an account number was reformatted — it sends a Notification of Change (NOC) instead of a return.
| NOC Code | Change | Action required |
|---|---|---|
| C01 | Incorrect account number | Update to new account number |
| C02 | Incorrect routing number | Update to new routing number |
| C03 | Incorrect routing and account number | Update both |
| C05 | Incorrect transaction code | Change account type (checking ↔︎ savings) |
| C09 | Incorrect individual ID number | Update receiver identification |
NOCs are mandatory to process. NACHA rules require originators to apply the corrected information within 6 business days or before the next entry to that receiver, whichever is later. Ignoring a NOC and resubmitting with the old information triggers a return — and repeat returns after NOCs draw NACHA enforcement attention.
Automating NOC processing is not optional at scale. A payroll platform originating 500,000 entries per month will receive hundreds of NOCs monthly. Manual processing introduces delay and errors. The system must parse NOC addenda records, extract the corrected fields, update the stored account information, and confirm the update before the next origination cycle.
Prefunding and ODFI Risk
The ODFI bears settlement risk for every entry it originates. If the originator’s funding account has insufficient funds when settlement occurs, the ODFI covers the shortfall from its own reserves and pursues the originator for recovery.
For credit originations (payroll, vendor payments), the risk is concentrated: the originator must have the total file amount available at settlement time. ODFIs manage this in three ways:
| Strategy | How it works | Who uses it |
|---|---|---|
| Prefunding | Originator deposits the full file amount before submission | Small/medium originators, new relationships |
| Same-day funding | Originator’s account is debited on the settlement date | Established originators with credit approval |
| Net settlement | ODFI nets credits against debits and funds only the difference | High-volume originators with balanced flows |
Prefunding is the simplest and most common for fintech platforms. Your bank requires you to fund the full amount of every file before it will submit the file to the ACH operator. The cash leaves your account immediately, but the recipients don’t see it until the next settlement window. Your capital is locked for 12–36 hours depending on timing.
For debit originations (subscription billing, loan payments), the risk inverts. The originator pulls money from receivers, and returns can arrive up to 60 days later. The ODFI’s exposure is the total debit volume outstanding within the return window. ODFIs set debit exposure limits — a cap on total outstanding debits — and require reserve accounts or surety bonds for originators with high debit volumes.
Volume and Scale
NACHA processed 31.5 billion ACH transactions in 2023, moving $80.1 trillion in value. The network handles an average of 86 million transactions per business day. Same-Day ACH accounted for 822 million of those transactions — 2.6% of volume but growing 20%+ year over year.
At these volumes, file processing has its own performance constraints. A single NACHA file can contain up to 10 million entries — the practical limit is set by the ACH operator’s file size caps and the ODFI’s processing capacity. A 10-million-entry file is approximately 940 MB of fixed-width text (94 bytes × 10M records plus batch and file records).
Parsing NACHA files is CPU-bound on character offset extraction, not I/O-bound on file reads. A naive parser that processes records sequentially handles approximately 500,000 records per second on modern hardware. Parallelizing by batch — each batch is independent and can be validated in isolation — scales linearly with cores. The batch hash and file control totals serve as integrity checks after parallel processing.
Large originators submit multiple files per processing window, partitioned by effective date, SEC code, or destination routing number range. Partitioning by routing number prefix allows the ACH operator to sort entries for delivery to RDFIs without a full file sort — entries destined for the same RDFI are already contiguous within the file.
See Payment Rails. ACH’s batch architecture is a design choice, not a limitation. The network was built for high-volume, low-urgency payments where next-day settlement is acceptable. For payments that need confirmation in seconds, the answer is FedNow or RTP — not Same-Day ACH with a shorter window.