2.1 File Hierarchy: 94-Character Records, Blocking Factors & File Header (Type 1)

2.1 File Hierarchy: 94-Character Records, Blocking Factors & File Header (Type 1)

Core Principle: The Automated Clearing House (ACH) Network operates as a batch-oriented, store-and-forward electronic funds transfer ecosystem. To ensure seamless interoperability among thousands of financial institutions, corporate originators, and ACH Operators (the Federal Reserve Bank's FedACH and The Clearing House's EPN), Nacha establishes strict, immutable structural specifications for all transmitted data.

Every participant preparing for the Accredited ACH Professional (AAP) examination must master the underlying technical blueprint of ACH files. File processing failures, operator rejections, and transmission delays almost invariably stem from formatting non-compliance, miscalculated blocking factors, or invalid header parameters.

---

The Hierarchical File Envelope Model

An ACH file is constructed using a nested envelope hierarchy. This structure allows financial institutions to aggregate thousands of individual debit and credit transactions into logically organized operational units with distinct clearing rules, settlement schedules, and legal warranties.

+-------------------------------------------------------------------------+
| FILE HEADER RECORD (Type 1)                                             |
|   +-------------------------------------------------------------------+ |
|   | COMPANY / BATCH HEADER RECORD (Type 5) - Batch 0000001            | |
|   |   +-------------------------------------------------------------+ | |
|   |   | Entry Detail Record (Type 6) #1                             | | |
|   |   |   Addenda Record (Type 7) #1 (Optional / SEC Dependent)     | | |
|   |   | Entry Detail Record (Type 6) #2                             | | |
|   |   | Entry Detail Record (Type 6) #3                             | | |
|   |   +-------------------------------------------------------------+ | |
|   | COMPANY / BATCH CONTROL RECORD (Type 8) - Batch 0000001           | |
|   +-------------------------------------------------------------------+ |
|   +-------------------------------------------------------------------+ |
|   | COMPANY / BATCH HEADER RECORD (Type 5) - Batch 0000002            | |
|   |   +-------------------------------------------------------------+ | |
|   |   | Entry Detail Record (Type 6) #1                             | | |
|   |   +-------------------------------------------------------------+ | |
|   | COMPANY / BATCH CONTROL RECORD (Type 8) - Batch 0000002           | |
|   +-------------------------------------------------------------------+ |
| FILE CONTROL RECORD (Type 9)                                            |
| PADDING RECORDS (All 9s records to complete 10-record block)            |
+-------------------------------------------------------------------------+

The Four Structural Levels

1. File Level (Outer Envelope): Delimited by a single File Header Record (Type 1) at the beginning and sealed by a single File Control Record (Type 9) at the end. It encapsulates all batches, establishes origin/destination routing, and accumulates file-wide control totals.
2. Batch Level (Inner Envelope): Delimited by a Company/Batch Header Record (Type 5) and sealed by a Company/Batch Control Record (Type 8). A file can contain one or multiple batches. Each batch isolates transactions that share identical origination characteristics, such as Standard Entry Class (SEC) code, Company ID, Effective Entry Date, and Service Class Code.
3. Entry Detail Level (Transaction Instruction): Defined by individual Entry Detail Records (Type 6). Each Type 6 record represents a specific financial or non-monetary transaction directed to an account at a Receiving Depository Financial Institution (RDFI).
4. Addenda Level (Supplemental Data): Represented by Addenda Records (Type 7) attached directly behind their parent Type 6 record. Addenda records convey electronic data interchange (EDI) remittance data, return reason codes, or Notification of Change (NOC) details.

---

The 94-Character Fixed-Length Standard

Every record within an ACH transmission—regardless of whether it is a header, detail, addenda, control, or padding record—must contain exactly 94 ASCII characters.

• No Delimiter Reliance: Fields within an ACH record are fixed-width and positional. They do not rely on commas, tabs, or variable tags. If a field contains fewer characters than its designated length, it must be padded with leading zeros (for numeric fields) or trailing blank spaces (for alphanumeric fields).
• Record Delimiters: While transmission protocols may append carriage return (CR) and line feed (LF) characters at byte positions 95 and 96 for stream parsing, the logical Nacha record payload is strictly 94 bytes. Any file containing records of 93 or 95 characters is immediately rejected by ACH Operator validation engines.

---

Blocking Factors & End-of-File Nines Padding

ACH files utilize a mandatory blocking factor of 10. This mainframe-era transmission optimization requires records to be grouped into physical transmission blocks of 10 records (940 characters).

$\text{Physical Block Size} = 10 \text{ records} \times 94 \text{ characters/record} = 940 \text{ characters}$

The Mathematical Padding Rule

If the total count of active logical records in a file (Type 1 + Type 5s + Type 6s + Type 7s + Type 8s + Type 9) is not an exact multiple of 10, the file must be padded with fill records containing ninety-four consecutive 9s (9999999999...) until the next multiple of 10 is reached.

$\text{Total Required Records} = \lceil \frac{\text{Active Records}}{10} \rceil \times 10$ $\text{Padding Records Required} = \text{Total Required Records} - \text{Active Records}$

Worked Example: Block Calculation

Suppose an ODFI generates an ACH file containing:

• 1 File Header Record (Type 1)
• 2 Company/Batch Header Records (Type 5)
• 18 Entry Detail Records (Type 6)
• 4 Addenda Records (Type 7)
• 2 Company/Batch Control Records (Type 8)
• 1 File Control Record (Type 9)

$\text{Active Logical Records} = 1 + 2 + 18 + 4 + 2 + 1 = 28 \text{ records}$ $\text{Block Count} = \lceil \frac{28}{10} \rceil = 3 \text{ blocks (30 total records = 2,820 characters)}$ $\text{Nines Padding Records} = 30 - 28 = 2 \text{ records (Records 29 and 30)}$

If this file were transmitted with only 28 records, the ACH Operator would reject the entire file with a fatal framing/blocking error.

---

Field-by-Field Specification: File Header Record (Type 1)

The File Header Record identifies the physical sender and receiver of the transmission, establishes file creation timestamps, assigns processing priorities, and prevents duplicate file ingestion.

---

Deep Dive: Critical File Header Mechanics

1. Immediate Destination vs. Immediate Origin Formatting

Nacha rules specify that routing transit numbers are 9 digits in length. Because Fields 3 and 4 are allocated 10 character positions, specific formatting rules apply:

• Immediate Destination (Positions 04–13): The receiving ACH Operator routing number (for example, 021000021) is preceded by a single blank ( 021000021).
• Immediate Origin (Positions 14–23): If the sending entity uses a 9-digit routing number, it is preceded by a space ( 121000358). If a 9-digit Federal Employer Identification Number (EIN) is used, it is commonly preceded by a 1 (1123456789).

2. The File ID Modifier & Duplicate File Detection

ACH Operators utilize a composite key to detect and reject duplicate file transmissions within their operational window: $\text{Duplicate Key} = \text{Immediate Origin} + \text{Immediate Destination} + \text{File Creation Date} + \text{File ID Modifier}$

If an ODFI transmits three distinct files to the Federal Reserve on October 24, 2026 (261024):

• File 1: File ID Modifier = A (Accepted)
• File 2: File ID Modifier = B (Accepted)
• File 3: File ID Modifier = A (REJECTED — Operator detects duplicate file key, even if the internal batch and dollar amounts differ).

If an ODFI exhausts alphabetic characters A through Z in a single day, it advances to numeric digits 0 through 9.