ACH Network, FedACH and EPN. A practitioner deep dive into the U.S. ACH infrastructure, covering FedACH and EPN, files and batches, inter-operator exchange, processing windows, settlement, RDFI distribution, statuses, resilience and reconciliation.
The Automated Clearing House, or ACH, is one of the most important pieces of payment infrastructure in the United States. It moves payroll, supplier payments, consumer bill payments, account transfers, government payments, healthcare payments, collections and many other forms of value every business day. Yet ACH is often explained too simply as “a batch payment rail.” That description is not wrong, but it hides the operating model that banks, processors, operations teams, architects and business analysts actually need to understand.
The ACH Network is a nationwide system through which depository financial institutions exchange batches of electronic credit and debit entries. Two national ACH Operators provide the central processing infrastructure: the Federal Reserve Banks through FedACH® Services and The Clearing House through the Electronic Payments Network, EPN®. These operators receive ACH files from originating financial institutions, perform operator-level edits and processing, sort entries for receiving institutions, distribute output and support settlement. The two operators are interoperable, so an ODFI can use one operator while the RDFI uses the other. Inter-operator items are exchanged between the operators, and the Federal Reserve settles inter-operator ACH positions.
That dual-operator model is fundamental. It means the ACH Network is not one single technical platform even though participants follow a common national rule framework. It also means a bank must understand three separate layers at once: Nacha rules and ACH business semantics, the technical and operational requirements of its chosen ACH Operator, and its own internal processing architecture.
The scale is enormous. Nacha reported that the ACH Network handled 35.2 billion on-network payments worth $93 trillion in 2025. The network continues to grow, including strong growth in Same Day ACH during 2026. The infrastructure therefore has to combine very high throughput with predictable processing windows, controlled settlement, strong file integrity, resilient connectivity and traceable reconciliation.
This chapter stays strictly on ACH infrastructure: the ACH Network, FedACH, EPN, operator processing, inter-operator exchange, timing, settlement, statuses, controls, reconciliation and operational architecture. Chapter 7 will go deeper into ACH credit payments, Chapter 8 into ACH debit collections, Chapter 9 into authorisation and SEC codes, Chapter 10 into Same Day ACH, and later chapters into returns, fraud, exceptions, reconciliation and connectivity. Where those topics are necessary here, they are explained only far enough to make the infrastructure understandable.
For a roughly 60-minute core session, spend about 35 minutes on Sections 2–3, Sections 5–6, Sections 8–9 and Sections 13–14. For the next 10 minutes, use the chapter’s three diagrams to distinguish ACH file delivery from settlement account movements. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: Which records prove operator processing, interbank settlement and customer posting separately? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Why the ACH Network is infrastructure, not just a payment type
- The ACH participant model from an infrastructure perspective
- ACH file, batch, entry and addenda architecture
- From Originator to ODFI: preparing ACH for network submission
- FedACH and EPN: the two national ACH Operators
- Inter-operator ACH: when ODFI and RDFI use different operators
- Operator processing: edits, sorting, distribution and control totals
- Processing windows, effective dates and settlement timing
- ACH settlement: how interbank obligations are actually discharged
- Standard ACH and Same Day ACH at the infrastructure layer
- From ACH Operator to RDFI: receiving and posting preparation
- Acknowledgements, statuses and observability in ACH processing
- Infrastructure exceptions and failure domains
- Reconciliation, settlement evidence and reporting
- Controls, connectivity, resilience and real-bank operating design
- End-to-end cases, BA checklist and testing
1. Why the ACH Network is infrastructure, not just a payment type
When people say “ACH payment,” they often mix together three different ideas.
The first is the business use case. Payroll, utility collections, supplier payments, tax refunds, mortgage debits and account transfers can all use ACH.
The second is the ACH entry itself. An ACH credit or debit is an electronic payment instruction carried according to ACH rules and file standards.
The third is the ACH Network infrastructure that moves those entries between financial institutions and supports settlement.
Chapter 6 is mainly about the third layer.
The ACH Network exists because thousands of financial institutions need a common way to exchange high volumes of electronic payments without creating direct bilateral connections to every other bank or credit union. An ODFI can collect entries from many Originators, combine them into ACH files, send those files to an ACH Operator, and rely on the operator to route the entries toward the correct RDFIs. The RDFIs then receive files or output containing the entries destined for them.
That centralised operator model provides scale. A bank does not need a custom payroll interface with every receiving bank. It needs a valid ACH relationship with its operator, valid routing and entry data, and a compliant ACH processing capability.
The infrastructure also separates payment exchange from settlement.
The file carries the payment instructions. The operator processes and routes them. Settlement then moves the corresponding interbank value between settlement accounts according to the relevant schedule. Customer posting happens inside the banks. Those are different events, as Chapter 4 already established.
For a bank architecture team, this means ACH cannot be represented by one box labelled ACH between the channel and the core ledger. A more realistic operating chain is:
customer/originator → channel or file gateway → payment ingestion → validation and entitlement → ACH formatting/batching → ODFI processing → ACH Operator → interbank settlement → RDFI processing → customer posting → reporting/reconciliation.
Some banks combine several of those functions in one payment engine. Others use separate products or processors. The business responsibilities remain even when the technology is consolidated.
The infrastructure is also not “always next day.” ACH includes standard processing and Same Day ACH processing windows. A payment can be submitted today for a future effective date, processed in one operator window and settled later. Another eligible payment can be processed and settled the same business day. The route is still ACH; the timing model differs.
Finally, ACH is not an instant-payment rail. Even when Same Day ACH moves quickly, it remains a batch-oriented ACH environment with operator windows and ACH rules. RTP and FedNow use real-time messaging and settlement models. That distinction is foundational and should remain clear throughout the academy.
A useful practitioner question is therefore not simply “Is this ACH?” but:
Who originated the entry, which ODFI accepted it, which ACH Operator processed it, which RDFI received it, when did settlement occur, and what evidence proves every hand-off?
That question turns a vague rail label into a real operating model.
2. The ACH participant model from an infrastructure perspective
Chapter 2 introduced the ACH roles. Here we revisit only the parts needed to understand the network architecture.
The Originator is the party that creates or causes an ACH entry to be initiated. It can be an employer sending payroll credits, a biller originating authorised debits, a corporate paying suppliers, a government agency making payments or another business or consumer use case supported by the rules.
The ODFI, or Originating Depository Financial Institution, is the financial institution that transmits ACH entries into the ACH Network. From an infrastructure perspective, the ODFI is the participant that stands between the Originator and the ACH Operator. The ODFI is not merely a file forwarder. It is responsible for accepting eligible origination, applying its customer and risk controls, forming or validating compliant ACH data, and submitting entries under the rules and its operator arrangements.
The ACH Operator receives ACH files from ODFIs, performs operator-level editing and processing, sorts entries by destination, creates output for RDFIs and supports settlement. In the United States there are two national ACH Operators: the Federal Reserve Banks' FedACH Services and The Clearing House's EPN.
The RDFI, or Receiving Depository Financial Institution, receives ACH entries for accounts it services. The RDFI processes the received entries, determines the account-level outcome under applicable rules and internal systems, posts debits or credits when appropriate, and reports or returns items when required.
The Receiver is the person or organisation whose account is affected by the ACH entry. The Receiver is not the same thing as the RDFI. One is the customer or account-holder role; the other is the financial institution role.
There can also be processors and third-party service providers between these roles. A large bank may transmit directly to FedACH or EPN. Another institution may use a processor's connection. An Originator may send a file to a treasury provider that transmits on its behalf. These technical intermediaries do not erase the legal and operational responsibilities of the ODFI and RDFI.
From a system-design perspective, it is useful to keep four concepts separate:
business originator — who wants the ACH payment created;
ODFI of record — which financial institution originates the entry into the network;
technical sender — which connection or processor transmits the file;
settlement party — which account or correspondent arrangement is used to settle the financial obligation.
In a simple bank, these may all point to one institution. In a sponsored or processed arrangement, they can differ.
The same separation is important on receipt. The RDFI of record may use a processor to receive and parse operator files. Customer posting may occur in a separate core. Reconciliation may be performed by another service. The technical path can therefore involve more components than the formal ACH participant chain.
A common architecture error is to map processor = ODFI or gateway = RDFI. A gateway transmits data. A participant bears the network role. A processor performs services. Those are different dimensions.
Direct operator connection versus processed access
Federal Reserve guidance makes the distinction practical. Financial institutions can establish FedACH origination and receipt services through FedLine solutions, and they can also use third-party service providers for transmission and receipt. A bank that uses a third-party connection still remains responsible for its own ACH activity and must control the service-provider relationship.
That creates several BA requirements that are often overlooked:
- Who owns the direct operator relationship?
- Who owns the routing number configuration?
- Who receives operator acknowledgements?
- Who has authority to submit or retrieve files?
- Who performs cut-off monitoring?
- Who reconciles settlement?
- Who handles contingency if the processor is unavailable?
- Can the bank independently view or verify its operator activity?
Those questions belong in infrastructure design, even though later chapters will cover deeper third-party risk and connectivity models.
3. ACH file, batch, entry and addenda architecture
The ACH Network is heavily file-oriented. To understand operator processing, a learner must understand the hierarchy inside an ACH file.
The Nacha file format uses fixed-length records. The most important training model is:
file → batch → entry → optional addenda.
The file begins with a File Header Record, record type 1. It identifies information relevant to the file and its immediate origin/destination context.
A file can contain multiple batches. Each batch begins with a Company/Batch Header Record, record type 5. The batch header identifies the Originator and carries information that applies to the entries in that batch, including the Standard Entry Class code and effective entry date concepts.
Inside the batch are Entry Detail Records, record type 6. Each entry represents an individual ACH payment instruction. It contains information such as transaction code, receiving routing information, receiving account identification, amount and a trace number assigned in the originating process.
Some entry types can carry Addenda Records, record type 7, to provide additional payment-related information. The amount and nature of addenda vary by ACH application and SEC code.
The batch closes with a Batch Control Record, record type 8. The batch control contains totals and control information used to validate the batch, including entry counts, dollar totals and an entry hash.
The file closes with a File Control Record, record type 9, containing file-level totals and control values.
This hierarchy matters operationally because errors and control totals exist at different levels.
A whole file can be rejected because the file is structurally invalid. A batch can contain inconsistent or invalid information. An individual entry can fail a processing rule. An addenda record can be malformed while the rest of the file structure is readable.
The bank's internal state model should therefore not assume one binary result for the whole file.
A realistic model can include:
FILE_RECEIVED
FILE_VALIDATED
FILE_ACCEPTED
BATCH_VALIDATED
ENTRY_ACCEPTED_FOR_ORIGINATION
FILE_TRANSMITTED_TO_OPERATOR
OPERATOR_ACKNOWLEDGED
and later settlement, distribution and RDFI-side states.
The exact status names are internal design choices. The key is that the hierarchy is preserved.
One file can represent many Originators
A customer-originated ACH file and an ODFI's operator file are not necessarily the same thing.
A corporate may send one file containing only its own batches. The ODFI can validate it and then combine batches from many customers into a larger operator file. This is one reason the file header seen by the bank's customer may differ from the file header transmitted by the ODFI to the ACH Operator.
A payment platform therefore needs lineage between:
customer file ID → bank ingestion file ID → ODFI operator file ID → batch ID → ACH trace number.
Without that lineage, operations may know that a customer uploaded a file but be unable to prove which operator submission carried a particular entry.
Control totals are not decorative fields
ACH uses counts, dollar totals and hash values to help prove file and batch integrity.
A batch control can confirm that the expected number and amount of debit and credit entries is present. The entry hash provides an additional integrity check based on routing data. File control aggregates the batches.
A good receiving process calculates control totals independently and compares them with the submitted values. The bank should not trust a customer-provided total simply because it is present.
These controls help detect file corruption, missing records, duplicate concatenation and transformation errors. They do not prove that the underlying business transaction is authorised or correct. An unauthorised debit can have perfectly valid control totals. Infrastructure integrity and business legitimacy are separate controls.
94-character records, blocking factor and padding
A production ACH file is not simply a text file with one payment per line. Under the Nacha file format, each physical ACH record is 94 characters long, and files are organised using a blocking factor of 10 records. That means the total record count of a properly blocked ACH file is a multiple of ten.
If the meaningful records do not naturally fill the final ten-record block, the remaining physical records are filled with padding records made entirely of 9 characters. These padding records are not additional File Control Records and they do not represent payments. They exist so the physical file satisfies the blocking requirement. The real File Control Record is still the record type 9 that carries the file-level counts, totals and hash information; any all-9 records after it are blocking filler.
This matters in real bank technology because parsers, file validators and test tools must distinguish record type 9 File Control data from all-9 padding. A parser that treats every line beginning with 9 as another financial control record can miscount the file or report false structural errors. Likewise, a file builder that forgets padding can create a file that looks readable to a human but does not meet the physical ACH file specification expected by the receiving process.
For developers and testers, three simple checks are therefore valuable: every ACH record should have the expected 94-character length; the final physical file should respect the ten-record blocking convention; and padding records must never be turned into business transactions or included in payment counts and dollar totals.
4. From Originator to ODFI: preparing ACH for network submission
The ACH Network begins before the operator ever sees a file.
An Originator can create payment instructions through a corporate file, online banking channel, API, payroll application, treasury workstation, biller platform or another supported channel. The ODFI's first responsibility is to convert that customer intent into a controlled ACH origination process.
The ODFI normally performs several layers of checking before operator submission.
First is customer and channel authority. Is this Originator entitled to create ACH entries from the funding account? Is the user or system authorised? Are file-level approvals complete? Are limits satisfied?
Second is technical validation. Is the file readable? Are required records present? Do file and batch controls balance? Are field formats and record counts valid? Are routing numbers syntactically plausible? Does the file use a supported ACH application?
Third is business validation. Is the requested processing date allowed? Is the account eligible? Is the transaction type consistent with the customer agreement? Does the batch contain the expected debit/credit classification? Are the Originator and company identifiers valid for that relationship?
Fourth is risk and compliance processing. Depending on the bank and use case, the ODFI may apply fraud controls, exposure limits, account controls, sanctions-related processes and other risk checks. Later chapters cover these controls in more depth.
Fifth is routing and operator preparation. The ODFI determines how and when to submit the entries to its ACH Operator and creates the operator-facing file or transmission.
This is where timing becomes operationally important. A customer cut-off is often earlier than the operator transmission deadline. The bank needs enough time to receive the customer file, validate it, repair or reject errors, complete approvals, build the outgoing operator file and transmit it completely before the operator window closes.
The difference between customer cut-off and operator deadline should therefore be explicit.
If the operator's deadline is 4:45 p.m. ET, the bank should not promise every corporate customer that a file uploaded at 4:44 p.m. will make that window. The bank may set an earlier customer deadline based on its processing architecture and service commitment.
Example: payroll file before the morning window
A corporation sends a payroll file to its bank early Monday. The file contains 18,000 credits. The requested payroll date is Tuesday.
The ODFI validates the file, checks totals, verifies the corporate's ACH origination entitlement and exposure, assigns internal identifiers, and places the batches into an outgoing operator file.
The operator may process the future-dated items during one of its windows. The settlement date remains Tuesday according to the applicable ACH timing rules. The receiving banks can receive the entries before settlement and prepare for posting according to their own operational process.
This example shows why FILE_SENT_ON_MONDAY does not mean PAYROLL_SETTLED_ON_MONDAY.
The file movement, operator processing and settlement date are separate events.
ODFI release is a meaningful control point
Many banks benefit from a formal RELEASED_TO_ACH state.
Before that point, a customer correction may still be possible under the bank's product workflow. After release to the operator, the handling options are different and depend on ACH rules and operator processing state.
The system therefore should timestamp the exact release and preserve:
- originator/customer reference;
- bank transaction ID;
- operator file ID;
- batch ID;
- trace number;
- release user/system;
- release timestamp;
- processing window targeted;
- effective entry date;
- settlement date once known.
That evidence becomes valuable in investigations and cut-off disputes.
5. FedACH and EPN: the two national ACH Operators
The United States has two national ACH Operators.
The Federal Reserve Banks operate FedACH Services.
The Clearing House operates the Electronic Payments Network, EPN.
Both provide ACH processing services. The Federal Reserve Board describes the Reserve Banks and EPN as the two national ACH Operators. Together they allow financial institutions across the country to exchange ACH payments under the Nacha operating framework.
FedACH
FedACH is operated by the Federal Reserve Banks. FedACH receives files from sending financial institutions, edits and sorts ACH items, distributes output to receiving institutions, and settles items through Federal Reserve accounts according to the applicable processing schedule and Operating Circular 4.
Operating Circular 4 is a particularly important source because it sets the Federal Reserve's legal terms for commercial ACH credit and debit items processed through FedACH. Financial institutions using FedACH also establish service and access arrangements with the Federal Reserve Banks.
Connectivity can be direct through Federal Reserve access services or supported through approved processing arrangements. Federal Reserve materials distinguish between institutions that maintain their own transmission capability and institutions that use third-party service providers.
EPN
EPN is The Clearing House's private-sector ACH service. It provides batch ACH processing for financial institutions and supports high-volume ACH origination and receipt. The Clearing House describes EPN as fully interoperable, meaning EPN customers can send ACH payments to receiving institutions even when the receiving institution is served by FedACH.
EPN processes a substantial share of U.S. commercial ACH volume. The Clearing House reports that EPN handles essentially half of U.S. commercial ACH volume and publishes annual volume and value statistics.
One ACH Network, two operator infrastructures
The presence of two operators should not be understood as two separate ACH schemes.
The network-level business framework is common, but the operator services are different infrastructures with their own customer relationships, connectivity arrangements, processing schedules, service documentation, support models and operator-specific procedures.
A large bank can choose the operator model that best suits its operational needs and can maintain complex routing and contingency arrangements. Smaller institutions may rely more heavily on correspondents or processors.
A BA or architect should therefore never write a requirement such as:
Send file to ACH.
The requirement should identify:
- which ACH Operator relationship is used;
- who transmits the file;
- which routing number/participant configuration applies;
- which processing window is targeted;
- what acknowledgement is expected;
- how settlement is evidenced;
- what contingency path exists if the operator or connection is unavailable.
That is the level at which the infrastructure becomes testable.
6. Inter-operator ACH: when ODFI and RDFI use different operators
The most important architectural feature of the two-operator model is interoperability.
Suppose Bank A originates through EPN and Bank B receives through FedACH. Bank A does not need to switch its customer to another rail and Bank B does not need to become an EPN customer just for this payment. The two ACH Operators exchange the relevant inter-operator items.
The Federal Reserve Board describes inter-operator ACH payments as payments where the originating and receiving depository financial institutions are served by different operators. The operators rely on each other to process those payments, and the Federal Reserve settles the inter-operator payments.
The reverse also works: an ODFI using FedACH can originate an entry destined for an RDFI served through EPN.
This architecture creates several important distinctions.
The ODFI sends to its operator, not necessarily the RDFI's operator
The originating bank normally submits according to its own operator relationship. It does not need to know the receiving bank's operator details in the same way it would select a direct network destination. The operator infrastructure handles routing and inter-operator exchange.
The ODFI still needs valid receiving routing information. The ACH Operator determines the path to the appropriate receiving side.
The inter-operator hop is an infrastructure event
For investigations and operational monitoring, the bank may need to know that an item crossed operators. However, the customer does not normally need to understand that FedACH and EPN were both involved.
A good internal data model can preserve operator path information without exposing unnecessary infrastructure detail to the customer.
Settlement responsibility changes by path
For FedACH customer items, the Reserve Banks settle according to FedACH arrangements.
For EPN in-network ACH, The Clearing House uses its settlement arrangement, including settlement through Federal Reserve infrastructure. For inter-operator ACH, the Federal Reserve settles the inter-operator positions.
The business implication is that message route and settlement route can be related but are not the same data event.
A bank may receive an operator output file from one service while the corresponding settlement evidence is reflected through Federal Reserve account activity or settlement reporting.
Interoperability makes operator concentration less visible to the end user
A corporate customer generally does not care whether its ODFI uses FedACH or EPN. It cares that the payment reaches the beneficiary account at the agreed time.
The bank, however, must care deeply because operator dependencies affect:
- transmission cut-offs;
- file acknowledgement timing;
- contingency procedures;
- support contacts;
- reconciliation feeds;
- settlement evidence;
- incident management.
That is why infrastructure documentation must go deeper than customer-facing product descriptions.
7. Operator processing: edits, sorting, distribution and control totals
Once an ACH Operator receives a file, it does not simply forward the bytes unchanged to every RDFI.
The operator performs processing functions that make a national ACH network possible.
At a high level, the operator receives incoming files, performs edits, validates structural and routing information, sorts entries for receiving institutions, creates output and settlement information, and distributes the resulting items to RDFIs or the other ACH Operator.
The exact operator implementation is proprietary and can differ, but the functional responsibilities are stable enough to model.
File acceptance and edits
The operator needs to determine whether the submitted file is processable.
This can include validating file structure, record sequencing, required fields, counts, control totals, routing information, effective dates, settlement eligibility and other operator rules.
A file that cannot pass critical operator edits may be rejected rather than partially processed. Other issues can affect individual batches or entries depending on the nature of the error and operator rules.
The bank needs to understand the unit of failure.
Is the whole file rejected?
Is one batch rejected?
Is one entry rejected?
Was a warning generated while processing continued?
Those outcomes must map to different internal states and customer responses.
Sorting by destination
The operator sorts entries so that each RDFI receives the items intended for accounts it services.
This is one of the major efficiency gains of the ACH model. An ODFI can send one file containing entries for hundreds of receiving institutions. The operator performs the distribution logic.
The RDFI then receives operator output that can contain entries from many ODFIs and Originators.
Settlement date insertion and processing metadata
The ACH format includes fields that can be populated or transformed during operator processing. One example is the settlement date information inserted by the ACH Operator into batch records under ACH processing conventions.
This is another reason the operator output is not always byte-for-byte identical to the originator input.
The bank's reconciliation design should distinguish customer-supplied fields from bank-enriched fields and operator-generated fields.
Trace numbers
ACH entries carry trace numbers assigned in the originating process. The trace number is a major operational identifier and should be preserved through reporting and investigations.
A trace number does not replace every other identifier. A customer may use its own payment reference. The bank can have an internal transaction ID. The operator file has its own identity. Reconciliation works best when all of those are linked.
File controls remain critical after transformation
If the ODFI groups customer batches into a larger operator file, the resulting file control totals need to reflect the operator submission, not the customer's original file.
Similarly, when the RDFI receives output, it should validate the received file against operator-provided controls.
A bank should be able to prove:
what it intended to send → what it actually transmitted → what the operator accepted → what settled.
That proof is the foundation of operational control.
8. Processing windows, effective dates and settlement timing
ACH is highly dependent on timing concepts.
A strong ACH design distinguishes at least:
- customer submission time;
- ODFI processing/release time;
- operator transmission deadline;
- operator distribution time;
- effective entry date;
- settlement date;
- settlement time;
- RDFI posting/availability time;
- reporting time.
Those times can be equal in some cases and different in others.
Current FedACH processing schedule
The times below are the published FedACH schedule, not a universal ACH-operator or bank-customer cutoff. EPN publishes separate operator-specific schedules. Its current Same Day ACH cutoffs distinguish inter-operator from intra-EPN transmission: 10:25 versus 10:55 a.m. ET, 2:40 versus 3:10 p.m. ET, and 4:40 versus 5:10 p.m. ET for the three windows. EPN also documents continuous inbound transmission subject to its maintenance window and business-day distribution rules. Apply the effective operator schedule for the participant and route; do not substitute FedACH times for EPN processing.
For non-Same-Day ACH credits, Nacha's rule effective September 18, 2026 generally requires the RDFI to make funds available by 9:00 a.m. RDFI local time on Settlement Date and removes the former 5:00 p.m. prior-day receipt condition. The rule includes separate treatment for certain RDFIs east of the Atlantic Time Zone and west of the International Date Line. This is an availability deadline, not a promise that every bank posts at exactly 9:00 a.m. or that customer posting, settlement and availability are the same event.
The Federal Reserve publishes the FedACH Processing Schedule. For same-day eligible forward items, the current schedule includes three major transmission deadlines and settlement times:
- 10:30 a.m. ET transmission deadline → 1:00 p.m. ET settlement;
- 2:45 p.m. ET transmission deadline → 5:00 p.m. ET settlement;
- 4:45 p.m. ET transmission deadline → 6:00 p.m. ET settlement.
FedACH also provides later processing windows for future-dated items and electronic returns. Future-dated items generally settle at 8:30 a.m. ET on the applicable future business day, subject to the processing rules.
The important training point is not to memorise every deadline forever. Schedules can change. The important design rule is:
processing windows and settlement schedules are external configuration, not hard-coded business truth.
A bank should source them from current operator documentation and control changes through release management.
Effective entry date is not a timestamp saying “send now”
The effective entry date expresses the intended ACH processing date at the batch level under ACH rules. The ACH Operator and rules determine the resulting settlement treatment.
A customer can submit a future-dated payroll file today for settlement on a future banking day.
A bank should therefore avoid using one field called paymentDate for:
- customer requested execution date;
- ACH effective entry date;
- operator settlement date;
- beneficiary posting date.
Those are different concepts.
Operator deadlines are not necessarily customer deadlines
EPN and FedACH each have operator processing arrangements. Banks also have their own customer cut-offs and processor cut-offs.
A customer contract can therefore say “same-day file cut-off 3:30 p.m.” even when an operator has a later network transmission deadline. The difference gives the bank time for validation, risk checks, file creation and transmission.
This distinction becomes essential during incidents.
If the customer sent at 3:29 p.m. and the bank missed the operator window because of an internal outage, that is a bank-processing failure.
If the customer sent after the published customer cut-off, it may be processed in a later window according to the service agreement.
Weekends and banking days matter
ACH processing schedules depend on banking days and operator windows. Standard ACH should not be designed as a 24/7 continuously settling service.
Instant payment platforms often use calendar-day timestamps. ACH platforms need clear banking-day logic, holiday calendars and effective-date calculations.
The bank's calendar service is therefore part of ACH architecture.
9. ACH settlement: how interbank obligations are actually discharged
ACH files move payment instructions. Settlement moves the interbank value.
This is one of the most important distinctions in Chapter 6.
When an ODFI sends ACH entries to the network, it creates obligations between financial institutions. Depending on whether the entries are credits or debits, the ODFI and RDFI positions move in different directions. The operator calculates or prepares the settlement information according to the processing cycle.
For FedACH items, the Federal Reserve Banks settle ACH obligations by posting debits and credits to the relevant financial institutions' Federal Reserve accounts according to the FedACH processing schedule and Operating Circular 4.
For EPN in-network items, The Clearing House arranges settlement through its ACH settlement process using Federal Reserve settlement infrastructure. Federal Reserve Board materials describe EPN in-network settlement through the National Settlement Service. Inter-operator ACH items are settled by the Federal Reserve.
The important architecture point is that the ACH Operator is not the customer's account ledger.
Customer A's bank may debit or credit Customer A's account.
Customer B's bank may debit or credit Customer B's account.
Between those banks, settlement occurs through interbank settlement accounts.
Settlement accounts can involve correspondents
Not every institution necessarily settles directly in its own Federal Reserve master account for every service relationship. A financial institution can use a correspondent or another account holder for settlement under the applicable Federal Reserve arrangements.
A bank's ACH system should therefore know:
- its operator relationship;
- its settlement routing arrangement;
- the Federal Reserve account or correspondent used;
- the general ledger accounts that represent ACH settlement;
- the reconciliation source used to prove settlement.
These are configuration data, not values that should be inferred from the ODFI routing number alone.
Credit entries and debit entries create different settlement directions
For an ACH credit, the ODFI is generally sending value toward the RDFI. The ODFI settlement position is debited and the RDFI side is credited at settlement.
For an ACH debit, the collection direction is reversed economically. The RDFI customer account is debited and value ultimately moves toward the ODFI side, subject to ACH processing and return rights.
Chapter 7 and Chapter 8 will explain those flows in detail. Here the infrastructure lesson is that one operator file can contain entries whose financial direction differs, and settlement processing must calculate the correct positions.
Settlement is not the end of ACH risk
Chapter 4 already explained that ACH settlement should not be treated as absolute business finality. ACH entries can later be returned under Nacha rules.
The settlement engine and the receivables engine therefore should not blindly interpret SETTLED as NO_FURTHER_RETURN_EXPOSURE.
The correct model is:
settlement proves that the interbank ACH settlement event occurred; later return or adjustment processes can create new financial events.
This distinction is especially important for debit collections.
Settlement reconciliation should use independent evidence
A bank should not mark an ACH file as settled merely because its internal scheduler reached the expected time.
It should reconcile against authoritative settlement information, operator reports or Federal Reserve account data appropriate to its setup.
Expected settlement and proven settlement are different states.
10. Standard ACH and Same Day ACH at the infrastructure layer
Same Day ACH is still ACH.
This point sounds obvious but prevents major architecture mistakes.
Standard ACH and Same Day ACH use the ACH Network, ACH Operators, ACH file structures and Nacha rule framework. Same Day ACH adds faster processing and settlement windows for eligible entries.
It does not turn ACH into RTP or FedNow.
What changes at the infrastructure layer
For Same Day ACH, timing becomes more compressed.
The ODFI must identify eligible entries and transmit them in time for a same-day operator window.
The operator processes the entries in the appropriate window.
Settlement occurs in the corresponding same-day settlement cycle.
The RDFI must meet applicable receipt and funds-availability obligations for same-day entries.
The bank's monitoring and reconciliation processes therefore need intraday operation rather than relying only on overnight batch completion.
What does not change
The basic ACH participant chain still exists.
The entries are still ACH entries.
The ACH Operators still process the files.
Return processes still exist.
The ODFI and RDFI remain responsible for their roles.
Current network scale
Same Day ACH has become a major part of ACH usage. Nacha reported 1.45 billion Same Day ACH payments in 2025 valued at $3.92 trillion, and strong growth continued in 2026.
This scale has operational consequences.
Same Day ACH can no longer be treated as a small special queue handled manually by one operations team. Large banks need automated eligibility decisions, window assignment, cut-off monitoring, settlement reconciliation and intraday exception handling.
Do not hard-code the dollar limit in generic infrastructure logic
Same Day ACH has a per-payment dollar limit governed by Nacha rules, and Nacha has approved future increases. Chapter 10 will cover the current and future limits in detail.
Chapter 6 should teach the design principle:
the eligibility limit is a rule-controlled parameter with an effective date, not a permanent software constant.
The same is true for processing windows and availability requirements.
Standard and same-day routing can share infrastructure
A bank can use one ACH ingestion platform that determines whether an entry qualifies for Same Day ACH or standard ACH based on requested timing, amount, SEC eligibility, customer product and cut-off.
The output can then be grouped into the appropriate operator submissions.
That is an example of a shared ACH platform with different processing lanes, not two separate payment rails.
11. From ACH Operator to RDFI: receiving and posting preparation
On the receiving side, the ACH Operator creates output for the RDFI containing the entries destined for accounts serviced by that financial institution.
The RDFI's job begins with controlled receipt.
Receive and validate operator output
The RDFI should securely retrieve or receive the operator file and verify that it is structurally complete.
Typical controls include:
- file identity and sequence checks;
- control totals;
- duplicate file detection;
- routing destination validation;
- expected processing window;
- received file count versus operator expectation;
- transmission integrity.
The receiving bank should not assume that “connection succeeded” means “all expected files arrived.”
A network connection can be healthy while one file is delayed or missed.
Parse entries into internal payment objects
The RDFI transforms operator records into its internal ACH processing model.
The bank should preserve the original ACH trace number, ODFI identification, company information, SEC code, amount, account identification, addenda and operator metadata required for processing and investigation.
Chapter 5's principle applies strongly here: do not discard original data merely because the core ledger needs only account and amount.
Account processing
The RDFI identifies the receiving account and evaluates whether the entry can be posted according to ACH rules and bank processing logic.
For credits, the bank prepares the account credit and availability treatment.
For debits, the bank prepares the account debit subject to the account condition and applicable controls.
Detailed credit and debit rules belong in Chapters 7 and 8.
Posting and settlement are related but separate
An RDFI can receive the ACH entry before the scheduled settlement event. The bank's posting process must therefore respect the applicable timing and availability rules.
The bank should not use file receipt time as settlement proof.
Likewise, settlement can occur while an internal posting exception remains unresolved.
A useful receiving-state sequence is:
OPERATOR_FILE_RECEIVED
ENTRY_PARSED
ACCOUNT_IDENTIFIED
POSTING_ELIGIBLE
SETTLEMENT_CONFIRMED
CUSTOMER_POSTED
REPORTED
The exact order can vary by product and processing design. The important point is that the states remain distinct.
Receive-only institutions still need strong ACH operations
A financial institution that originates very little ACH can still receive huge volumes of payroll credits, bill debits and account transfers.
Receiving capacity therefore needs independent scalability.
Peak-day volume, payroll cycles, tax days, government benefit dates and year-end processing can create operational spikes.
Capacity planning should be based on received transaction volumes and file sizes, not only origination volumes.
12. Acknowledgements, statuses and observability in ACH processing
ACH status behaviour differs significantly from instant-payment networks.
An RTP or FedNow payment can have rapid transaction-level network status messages. ACH is file and batch oriented. Banks therefore need to distinguish operator file acknowledgements from the later business outcome of individual ACH entries.
File acknowledgement is not customer payment completion
When the operator acknowledges receipt or acceptance of an ACH file, it proves an infrastructure event.
It does not prove that every receiving account has posted.
It does not prove that the payment cannot later be returned.
It does not necessarily prove settlement has already occurred.
A bank should map operator acknowledgements to precise internal states such as:
OPERATOR_FILE_RECEIVED
OPERATOR_FILE_ACCEPTED
or
OPERATOR_FILE_REJECTED.
Customer-facing statuses may remain Scheduled or Processing until the product-defined completion point.
File-level and entry-level observability
A mature ACH platform should let operations move from a high-level file to a specific payment.
For example:
ODFI operator file 20260901-ACH-044 → batch 17 → entry trace 123456780001234 → customer payment ID PAY-883194.
And in the reverse direction:
customer payment ID → batch → operator file → settlement cycle → RDFI output evidence.
Without this navigation, investigation becomes manual file searching.
Status provenance matters
Each status should record where it came from.
BANK_VALIDATED came from the ODFI's payment engine.
OPERATOR_ACCEPTED came from an ACH Operator acknowledgement.
SETTLEMENT_CONFIRMED came from settlement evidence.
RDFI_POSTED may be an internal RDFI event.
RETURN_RECEIVED is a later network event.
One generic SUCCESS flag loses that provenance.
Never collapse four different evidence points
For ACH operations, four events that are often casually called “processed” should remain separate in the data model and in operational reporting.
Operator acceptance proves that FedACH or EPN accepted the relevant file or submission for processing. It is evidence about the network hand-off. It is not settlement proof.
Settlement confirmation proves that the relevant interbank ACH settlement event occurred for the applicable settlement cycle. It is financial-infrastructure evidence, but it does not prove that a specific receiving customer account has already posted successfully.
RDFI receipt proves that the receiving institution obtained the operator output containing the entry. Receipt can occur before settlement and before customer posting, so it needs its own timestamp and provenance.
Customer posting proves that the RDFI's ledger actually applied the debit or credit to the customer account. This is an internal account event and can be delayed by an account-level exception even when operator processing and settlement are otherwise correct.
A strong operational timeline can therefore show OPERATOR_ACCEPTED → SETTLEMENT_CONFIRMED → RDFI_RECEIVED → CUSTOMER_POSTED while allowing the actual timing of receipt and settlement to differ according to the ACH processing model. The point is not to force one universal chronological order; the point is to preserve four independent pieces of evidence.
That distinction is crucial during incidents. If a customer says “my ACH payment is missing,” operations should be able to establish exactly which of the four evidence points exists rather than answering from a generic green status.
Expected versus observed events
An operations dashboard should distinguish what should have happened from what actually happened.
Example:
- file transmission expected 14:20 ET;
- transmission completed 14:18 ET;
- operator acknowledgement expected by 14:25 ET;
- acknowledgement received 14:19 ET;
- target settlement 17:00 ET;
- settlement evidence received 17:02 ET;
- reconciliation complete 17:08 ET.
This event timeline allows teams to detect delays before customers complain.
Monitoring the missing event
Payment monitoring often focuses on negative statuses such as REJECTED.
In ACH, a more dangerous problem can be the absence of an expected file or acknowledgement.
If an operator output file normally arrives at 5:30 p.m. and nothing arrives, the system needs an alert even though there is no explicit error message.
That is why ACH observability must include timer-based and schedule-based controls.
13. Infrastructure exceptions and failure domains
ACH infrastructure can fail at many different layers. Good operational design begins by identifying the failure domain.
Customer file failure
The Originator's file can be malformed, incomplete, duplicated, inconsistent or late.
The ODFI owns the customer communication and decision according to the product agreement.
This is not an ACH Operator outage.
Bank ingestion failure
The customer's file can be valid but the ODFI's ingestion service can fail.
Examples include storage failure, queue outage, parser failure or internal database unavailability.
The bank should preserve the original file and avoid ambiguous retry behaviour that could create duplicate origination.
ODFI validation or release failure
The file can pass syntax but fail business controls, exposure checks, approvals or risk processing.
The payment has not yet reached the operator.
The status should make that clear.
Transmission failure
The ODFI creates a valid operator file but the connection fails during transmission.
This is one of the most important duplicate-risk scenarios.
The bank must determine whether the operator received the file before retransmitting it.
Blindly sending the same business content again under a new file identity can create duplicate ACH entries.
A safe retry design uses transmission evidence, file identifiers, duplicate controls and operator support procedures.
Operator rejection
The operator can reject a submitted file or identify processing issues.
Operations needs the operator reason, the affected unit and a controlled remediation path.
Do not automatically “repair and resend” without checking whether any part of the original file processed.
Inter-operator issue
A FedACH/EPN inter-operator exchange can encounter an operational problem even when the originating bank's own operator accepted the file.
The bank's incident team needs to know whether the issue is local, operator-specific or inter-operator.
This affects customer communication and contingency decisions.
Settlement delay or break
The payment instructions can be processed while settlement is delayed or fails according to the relevant infrastructure rules.
The bank should distinguish:
OPERATOR_PROCESSED
from
SETTLEMENT_CONFIRMED.
Treasury and operations may need different alerts.
RDFI posting failure
The ACH Network can process and settle an entry while the RDFI's customer-posting system fails.
That is an internal receiving-bank exception, not evidence that ACH settlement failed.
Return is a later business event, not an infrastructure rejection
ACH returns belong in Chapter 11. The important distinction here is:
an operator/file rejection prevents or interrupts the original processing; a return is a new ACH event that follows an entry that was previously processed.
Collapsing both into FAILED makes operations and accounting much harder.
Incident ownership matrix
A bank should be able to assign ownership quickly:
- customer file problem → channel/origination support;
- internal parser problem → payment platform;
- FedLine connectivity problem → infrastructure/FedLine support;
- FedACH processing issue → Federal Reserve support path;
- EPN processing issue → TCH support path;
- settlement break → treasury/settlement operations;
- RDFI posting failure → core/account processing;
- missing reconciliation feed → finance/reconciliation support.
This is why one “ACH Operations” queue is often insufficient for a large bank.
14. Reconciliation, settlement evidence and reporting
ACH processing generates multiple evidence sources. Reconciliation proves that they agree.
A mature ODFI should be able to reconcile:
customer accepted entries → bank outbound ACH entries → operator accepted entries → settlement positions → customer debits/credits and GL postings.
A mature RDFI should be able to reconcile:
operator received entries → settlement positions → customer account postings → returns/adjustments → GL and customer reporting.
File reconciliation
At file level, the bank can compare:
- number of files sent;
- number acknowledged;
- number rejected;
- batch count;
- entry count;
- debit total;
- credit total;
- operator control totals.
A missing file is a break even when all other files balance.
Transaction reconciliation
At entry level, the bank links the original customer payment to the ACH trace number and operator processing evidence.
This is especially important when one customer file is split into several operator files or when the bank aggregates many customer files into one operator submission.
Settlement reconciliation
The bank calculates the expected net settlement impact from processed ACH activity and compares it with authoritative settlement entries.
A difference can arise from:
- file not included in the expected cycle;
- duplicate internal accounting;
- operator reject not reflected internally;
- timing difference;
- return or adjustment posting;
- correspondent settlement arrangement;
- fee or service entry;
- incorrect cycle assignment.
Operations should not force-balance by posting a manual GL adjustment without identifying the underlying cause.
GL reconciliation
ACH accounting often uses technical clearing, settlement and suspense accounts.
The general ledger should prove that the financial movement created by ACH processing has been recorded completely and only once.
A sound design tracks:
payment amount → customer account entry → ACH clearing/settlement account → Federal Reserve or correspondent settlement evidence → GL position.
Reporting to customers
Customer reporting can include accepted files, rejected files, payment status, account statement entries, return information and remittance data.
The channel should not invent a status based only on file acknowledgement.
The reporting layer needs a product-defined mapping from internal ACH states to customer language.
Operational reporting
Banks also need internal dashboards for:
- volume by operator;
- volume by window;
- same-day versus standard volume;
- file rejects;
- processing latency;
- missed cut-offs;
- duplicate alerts;
- settlement breaks;
- unreconciled items;
- aged suspense;
- return trends;
- processor outages.
Those metrics help distinguish a one-off customer problem from a systemic ACH issue.
15. Controls, connectivity, resilience and real-bank operating design
ACH is a high-volume system. The controls therefore have to work at scale.
Connectivity is part of the payment control environment
FedACH customers can use Federal Reserve access solutions such as FedLine services, directly or through approved service-provider arrangements. EPN customers use The Clearing House's connectivity and processing arrangements.
The specific technology can change over time. The enduring requirements are:
- authenticated access;
- authorised users or systems;
- encryption and transport security;
- file integrity;
- controlled certificates/keys;
- segregation of duties;
- access logging;
- transmission evidence;
- contingency connectivity.
Duplicate prevention must operate at multiple levels
ACH duplicate risk can arise from customer resubmission, internal retry, processor retry or operator-file retransmission.
A strong duplicate-control strategy uses more than one key.
Possible dimensions include:
- customer file ID;
- content hash;
- company ID;
- effective date;
- batch number;
- trace number;
- account/amount combination;
- internal business payment ID.
No single field is perfect for every use case.
The goal is to prevent accidental re-origination without blocking legitimate recurring payments.
Segregation of duties
High-value ACH origination should not depend on one user being able to create, approve and release a file without oversight.
Banks commonly separate:
- customer creation/approval;
- bank repair;
- bank release;
- operator configuration;
- settlement-account administration;
- production support access.
The exact control model depends on risk appetite and organisation design.
Cut-off monitoring
Every operator window should have pre-cut-off and post-cut-off controls.
Before the deadline, operations should know:
- which customer files are waiting;
- which batches are still in repair;
- whether the operator connection is healthy;
- whether the outgoing file has been built;
- whether risk approvals are complete.
After the deadline, operations should know:
- whether transmission completed;
- whether acknowledgement arrived;
- whether the file was accepted;
- what settlement cycle is expected.
This is much stronger than discovering at reconciliation that a file never left the bank.
Capacity and peak-day engineering
ACH volume is highly seasonal and event-driven.
Payroll days, month-end, quarter-end, tax dates, government benefits and large corporate settlement cycles can create significant peaks.
A bank should test not only average daily volume but:
- maximum files per minute;
- maximum entries per file;
- largest file size;
- peak concurrent validation;
- outbound aggregation time;
- operator-window compression;
- recovery after outage;
- backlog drain rate.
The critical question is not “Can the system process 100 million entries in a day?” but “Can it process the peak load before the next non-negotiable operator deadline?”
Business continuity
ACH resilience needs a documented contingency plan.
Possible disruptions include:
- primary data-centre outage;
- processor outage;
- FedLine or operator connectivity failure;
- operator incident;
- corrupted file generation;
- settlement-account issue;
- cyber event;
- key/certificate failure.
The bank should define:
- alternate transmission method where available;
- backup site or service;
- manual escalation process;
- operator contact procedures;
- decision rights for holding or rerouting files;
- customer communication;
- safe replay/retry rules;
- evidence required after recovery.
Do not build “operator failover” as an assumption
Because FedACH and EPN are interoperable, teams sometimes assume a bank can instantly switch from one operator to the other during an incident.
That is not a safe architectural assumption.
Operator participation requires commercial, legal, technical, routing, settlement, security and testing arrangements. A bank can design contingency involving both operators only if those arrangements actually exist and have been tested.
Interoperability between operators is not the same as automatic customer-level operator portability.
Configuration governance
ACH infrastructure depends heavily on reference data and configuration:
- routing numbers;
- operator participation;
- processing windows;
- holidays;
- customer cut-offs;
- SEC eligibility;
- Same Day ACH parameters;
- settlement accounts;
- processor relationships;
- limits;
- return timing;
- file format versions.
Changes to this configuration should be versioned, approved, tested and effective-dated.
Hard-coded schedules create avoidable operational risk.
16. End-to-end cases, BA checklist and testing
A strong Chapter 6 should leave the learner able to reconstruct an ACH infrastructure flow without memorising every ACH code.
Case 1 — payroll through FedACH
A corporate customer submits a payroll file with 25,000 credit entries to Bank A.
Bank A validates the customer file, confirms control totals, verifies the customer's ACH entitlement and exposure, checks the effective entry date and assigns internal payment IDs.
The bank aggregates the customer batches with other corporate batches into an ODFI operator file.
The outbound file is transmitted through Bank A's FedACH connection before the applicable FedACH deadline.
FedACH receives the file, applies operator edits, sorts the entries and produces output for receiving institutions. Entries for RDFIs served by FedACH remain within the FedACH path. Entries for RDFIs served by EPN are transferred through the inter-operator process.
The Federal Reserve settles the relevant ACH obligations at the applicable settlement time. RDFIs post payroll credits to employee accounts according to ACH rules and their processing arrangements.
Bank A reconciles:
- 25,000 customer entries accepted;
- 25,000 entries included in ODFI output;
- operator file acknowledged;
- expected debit settlement position;
- Federal Reserve settlement evidence;
- customer account funding debit;
- customer reporting.
If Bank A can prove every line of that chain, the infrastructure is operating correctly.
Case 2 — EPN ODFI to FedACH RDFI
Bank X originates through EPN. It sends an ACH supplier credit to an account at Bank Y, which receives through FedACH.
Bank X submits the entry to EPN.
EPN accepts and processes the originating file.
Because Bank Y is on the other operator path, the entry moves through the EPN-to-FedACH inter-operator process.
FedACH distributes the receiving output to Bank Y.
The inter-operator settlement is handled through the Federal Reserve settlement process.
Bank Y posts the credit to the supplier.
The customer sees only an ACH credit. Internally, operations can trace both operators.
This case proves the difference between network reachability and operator membership. Bank X does not need Bank Y to be an EPN customer for the ACH entry to reach it.
Case 3 — uncertain transmission and duplicate risk
Bank A creates an outbound FedACH file containing 400,000 entries.
The transmission starts before the deadline, but the network connection fails near completion. The sender does not receive a normal completion confirmation.
A poor implementation immediately creates a new file and retransmits all 400,000 entries.
A strong implementation pauses and determines whether the original file was fully received or accepted by the operator. It uses file identity, transmission logs, operator acknowledgement status and support procedures.
If the operator already received the first file, blind resubmission could create duplicate entries.
This case demonstrates why retry logic is a payment control, not just an infrastructure setting.
Case 4 — settlement expected but not reconciled
A same-day ACH cycle is expected to settle at 5:00 p.m. ET.
The ODFI's internal system marks 1.2 million entries as EXPECTED_SETTLEMENT_1700.
At 5:07 p.m., the reconciliation process has not received the expected settlement evidence.
The correct response is not to mark all entries failed. Operations checks the settlement feed, Federal Reserve account data, operator status, timing and internal ingestion services.
The payment instructions may have processed correctly while the bank's reconciliation feed is delayed.
This case demonstrates why payment processing, settlement and settlement evidence ingestion are three separate states.
BA requirement checklist
For an ACH infrastructure requirement, the analyst should be able to answer all of the following.
Scope and participant model
- Is the bank acting as ODFI, RDFI or both?
- Which ACH Operator relationship applies?
- Is the bank directly connected or using a processor?
- Which routing numbers are enabled for origination and receipt?
- Which settlement account or correspondent arrangement applies?
File and data
- What input formats are supported from customers?
- How are customer files transformed into operator files?
- How are file, batch and entry identifiers preserved?
- How are control totals validated?
- How are duplicates detected?
- How are addenda preserved?
Timing
- What customer cut-offs apply?
- Which operator windows are targeted?
- How is the effective entry date validated?
- How are holidays and banking days calculated?
- What happens when a file misses a window?
- Which same-day eligibility parameters are effective-dated?
Operator processing
- What acknowledgement is expected?
- What constitutes operator acceptance?
- What file/batch/entry rejection conditions are handled?
- How are inter-operator items identified if needed?
- How are operator outages monitored?
Settlement
- How is expected settlement calculated?
- What authoritative settlement evidence is consumed?
- Which GL accounts are used?
- What happens if settlement evidence is late or mismatched?
- Who owns treasury escalation?
RDFI processing
- How are operator files received and validated?
- How are accounts identified?
- How are credits/debits posted?
- How are posting exceptions queued?
- How are customer reporting and statements updated?
Controls and resilience
- What authentication and access controls protect operator connectivity?
- What segregation of duties applies?
- How are transmission retries made safe?
- What is the disaster-recovery path?
- How are operator contact and contingency procedures maintained?
Reconciliation and reporting
- Can customer payment be traced to ACH trace number?
- Can trace number be traced to operator file?
- Can operator file be traced to settlement cycle?
- Can settlement cycle be reconciled to Federal Reserve/correspondent activity and GL?
- Can operations identify missing expected files automatically?
If any of those answers is “we will work it out later,” the infrastructure requirement is not complete.
Testing strategy
A Chapter 6 test plan should cover more than one happy-path ACH file.
File structure tests should include valid files, invalid headers, incorrect record sequence, bad control totals, duplicate files, multiple batches, empty batches, unsupported record combinations and malformed addenda.
Batch and entry tests should include mixed customers, different effective dates, routing variations, credits and debits, large entry counts and maximum supported file sizes.
Operator tests should verify successful transmission, acknowledgement, rejection handling, duplicate transmission behaviour, delayed acknowledgement and recovery after connection loss.
Inter-operator tests should include originations where the RDFI is served through the other ACH Operator, with traceability across the hand-off.
Timing tests should exercise each supported processing window, customer cut-offs, late files, holidays, future-dated files and same-day eligible versus ineligible entries.
Settlement tests should reconcile expected debit/credit positions to settlement evidence and include delayed settlement feed, mismatched totals and correspondent-settlement scenarios.
RDFI tests should include output-file receipt, duplicate output, missing file detection, posting success, account-posting exception and reporting.
Resilience tests should include network interruption mid-file, processor outage, operator unavailable, certificate failure, failover to backup infrastructure where actually supported, backlog recovery and safe replay.
Performance tests should simulate peak-day volume before a real operator cut-off. A system that finishes eventually but misses the window has failed the business SLA.
The Chapter 6 mental model
By the end of this chapter, the learner should be able to explain the ACH infrastructure in one continuous chain:
Originator creates ACH intent → ODFI validates and batches → ODFI submits to FedACH or EPN → ACH Operator edits and sorts → inter-operator exchange occurs when required → entries are distributed to RDFIs → interbank settlement occurs at the applicable ACH settlement time → RDFIs post customer entries → banks report and reconcile → later returns or adjustments are handled as new ACH events.
The learner should also be able to answer five questions without hesitation:
- Why are FedACH and EPN both part of one ACH Network?
- What happens when the ODFI and RDFI use different operators?
- Why is operator file acceptance not the same as settlement or customer posting?
- Why must the bank preserve file, batch, trace and settlement lineage?
- Why is ACH retry logic a financial-control issue rather than only a technical issue?
If those answers are clear, the learner is ready for Chapter 7, where the academy moves from ACH infrastructure into the detailed mechanics of ACH Credit Payments.
Production-control view of the ACH operator boundary
A bank-grade ACH implementation needs an explicit control boundary between internal acceptance and operator acceptance. When a corporate file is received, the bank may accept the file technically while individual batches or entries are still subject to customer entitlement, exposure, fraud, format, effective-date and routing controls. The payment should not be described as sent to the ACH Network until the bank has actually released the relevant output to its ACH Operator. Likewise, successful transmission does not by itself prove operator acceptance, settlement or RDFI posting. Each hand-off needs its own state and evidence.
At the file layer, operations should be able to reconstruct file control totals, batch counts, entry counts, debit and credit totals, transmission identifiers, operator acknowledgements and rejected or corrected items. At the transaction layer, the bank needs correlation from customer reference through internal payment identifier, ACH trace number, settlement date and downstream posting or return events. This dual file-and-entry lineage is essential because an ACH incident can affect an entire transmission, one batch, one entry or only the downstream posting of an otherwise valid entry.
The dual-operator model also creates practical resilience requirements. A bank should know which operator relationship is primary for each service, what connectivity and authentication mechanisms are used, how acknowledgements are monitored, how missed windows are detected, and what contingency procedures exist if the bank cannot originate or receive normally. Contingency design must not assume that simply switching a network endpoint is sufficient; operational agreements, file sequence controls, duplicate prevention, settlement arrangements, security credentials and reconciliation processes all have to remain consistent.
Processing-window logic belongs in the payment engine, not in an operations spreadsheet alone. The engine should distinguish requested execution date, effective entry date, submission deadline, operator processing window and settlement date. When an instruction misses a window, the outcome should follow a defined rule: move to the next eligible window, move to the next banking day, reject, hold for customer decision or use another service only when the product explicitly permits alternative routing. Silent date changes create customer, liquidity and reconciliation risk.
Receiving-side processing deserves equal control. An RDFI receiving operator output should validate file integrity, identify settlement date and destination accounts, prevent duplicate ingestion, post eligible entries, route exceptions, generate customer reporting and preserve traceability to the operator source. A receiving failure after operator distribution is not the same as an operator failure. Production monitoring should therefore expose whether an item is waiting for operator output, received but not ingested, ingested but not posted, posted but not reported, or financially unreconciled.
Finally, reconciliation must connect three truths: what the bank intended to originate or receive, what the ACH Operator processed and settled, and what the bank actually posted to customer and internal accounts. Differences can arise from rejects, reversals, late returns, duplicate suppression, cut-off handling, file recovery or posting failures. A controlled close does not merely compare aggregate debit and credit totals; it explains every difference and carries unresolved items into an owned exception process with ageing, evidence and escalation. That is what turns ACH from a file-transfer capability into a reliable banking service.
A mature operating model should also distinguish recoverable technical failure from business rejection. A transport retry can be safe only when idempotency, file identity and operator acknowledgement state are known. If the bank cannot establish whether a file or batch was accepted, the item should move into an uncertain-outcome process rather than automatic retransmission. Operations needs tools to compare local transmission history with operator evidence before deciding whether to resend. This is one of the most important duplicate-prevention controls in production ACH processing.
Official and primary references
Federal Reserve Board — Automated Clearinghouse Services
https://www.federalreserve.gov/paymentsystems/fedach_about.htm
Federal Reserve Financial Services — FedACH Services
https://www.frbservices.org/financial-services/ach
Federal Reserve Financial Services — FedACH Processing Schedule
https://www.frbservices.org/resources/resource-centers/same-day-ach/fedach-processing-schedule.html
Federal Reserve Financial Services — Operating Circular 4, Automated Clearing House Items
https://www.frbservices.org/resources/rules-regulations/operating-circulars.html
Federal Reserve Financial Services — Conducting ACH Business with the Federal Reserve Banks
https://www.frbservices.org/financial-services/ach/service-setup/conducting-ach-business.html
Federal Reserve Financial Services — FedACH Origination and Receipt Services Setup
https://www.frbservices.org/financial-services/ach/service-setup/origination-receipt.html
Federal Reserve Financial Services — National Settlement Service
https://www.frbservices.org/financial-services/national-settlement-service/
The Clearing House — EPN / ACH Services
https://www.theclearinghouse.org/payment-systems/ach
The Clearing House — EPN Network Volume and Value Statistics
https://www.theclearinghouse.org/payment-systems/ACH/EPN-Annual-Statistics
Nacha — ACH Network Volume and Value Statistics
https://www.nacha.org/content/ach-network-volume-and-value-statistics
Nacha — ACH Guide for Developers: ACH File Overview
https://achdevguide.nacha.org/ach-file-overview
Nacha — ACH Guide for Developers: ACH File Details
https://achdevguide.nacha.org/index.php/ach-file-details
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.