How ACH Payment Processing Works in U.S. Banking

ACH payment processing in U.S. banking follows a precise path from payment instruction to settlement. Banks and credit unions weighing automation remain responsible for what they send into the network, even when they can create files faster. To automate responsibly, they need to know how each handoff works, keep proof of authorization, and build controls that cover the full payment lifecycle.

What the ACH Network is and why it exists

The Automated Clearing House, or ACH, is the batch-processing electronic funds transfer system behind much of everyday U.S. banking. Nacha describes the network as the mechanism supporting direct deposit, bill payment, and other domestic electronic fund movement. Its roots reach back to the early 1970s, and it became a national system in 1978. This is established infrastructure. Its reach makes its operating rules relevant to institutions of every size.

Nacha governs the network through the Nacha Operating Rules and Guidelines, but it does not process payments. That work belongs to two ACH Operators, the Federal Reserve Bank, operating as FedACH, and The Clearing House, operating as the Electronic Payments Network, or EPN. The operators are fully interoperable and exchange payments multiple times each day. Batching is a deliberate part of this design. Grouping thousands of transactions into scheduled settlement windows keeps costs low and makes the network broadly accessible.

The four parties in every ACH transaction and what each one is responsible for

Every ACH payment follows the same four-role chain, regardless of its amount or purpose. The Originator is the business or individual initiating the instruction and is responsible for obtaining valid authorization. The Originating Depository Financial Institution, or ODFI, accepts those instructions, validates them against technical standards, and transmits them into the network. The ACH Operator sorts entries by the routing number of their destination. The Receiving Depository Financial Institution, or RDFI, then credits or debits the Receiver’s account.

An employer acts as the Originator, sending employee banking information, payment amounts, and the pay date to its ODFI. The operator routes the entries to the employees’ RDFIs, which credit their accounts. A utility-bill debit takes the same path. In that case, the utility originates an authorized collection through its ODFI, and the customer’s RDFI debits the customer’s account.

Who answers for an instruction entering the network? The ODFI is legally responsible to Nacha for every transaction it sends. Because of that responsibility, some institutions choose not to serve in that role. Businesses may reach an ODFI through their bank or through a third-party payment processor with an ODFI relationship. That extra layer does not remove the originating institution’s accountability. The RDFI also has its own posting duties and, under the 2026 rules, must do more fraud monitoring.

The ACH payment lifecycle from file creation through settlement

Authorization must be in place before the payment entry is created. For a debit, the Receiver’s permission must already exist and be documented. The Originator then assembles a Nacha-format file containing header, batch, entry, and trailer records. These records must reconcile with one another. If trailer totals do not match the entries, the operator rejects the entire file, so an apparently small construction error can prevent otherwise valid instructions from moving forward.

The ODFI groups the Originator’s entries with others and transmits them at scheduled intervals. The operator receives the file, sorts its entries by destination routing number, and routes them to the appropriate RDFIs. Each RDFI posts the instructed credit or debit to the Receiver’s account, and funds settle at Federal Reserve accounts. Timing depends on the type of entry. Credits can settle the same day, the next banking day, or in two banking days, while operator edits enforce the rule that debits cannot have a settlement date more than one banking day ahead.

Nacha reports that 80% of ACH payments settle in one banking day or less. Same Day ACH can settle eligible entries within hours if they are sent within the set submission windows, but the network does not settle on weekends or federal holidays. Settlement is not the end of exposure. When payments fail, return codes explain why, and an unauthorized-payment claim can arrive weeks after the payment first settles. The ODFI therefore remains liable after the file has been sent and the payment posted.

Since March 20, 2026, Nacha has required “PAYROLL” for wage and salary credits to consumer accounts and “PURCHASE” for consumer debits for online purchases of tangible goods. These standardized Company Entry Descriptions form part of the payment instruction’s required content. Technical acceptance consequently depends on more than correct account information and matching totals.

ACH credits versus ACH debits — how the authorization rules differ and why it matters operationally

A credit pushes money into the Receiver’s account, while a debit pulls money from it. That distinction changes where authorization risk sits. With direct deposit, the employer initiates an outgoing payment using the banking information the employee provided. With utility autopay, mortgage payments, subscriptions, or insurance premiums, the collecting business initiates a debit against someone else’s account. The Receiver must have authorized that collection in advance.

A debit is an unauthorized ACH transaction if proper authorization was not in place beforehand. A credit may have been authorized under false pretenses, as happens in authorized push payment fraud, business email compromise, or payroll redirection. Both belong in the risk assessment, even though they arise at different points in the payment relationship.

Business accounts have less time than consumer accounts to return unauthorized debits, which also changes how payments are handled. Calendar conventions also affect execution. Common practice favors consumers by paying weekend or holiday paydays on the prior Friday while collecting bills on the next business day. For institutions evaluating automated origination, the lesson is to encode those timing conventions and preserve authorization evidence without treating every payment type alike. An AI-assisted instruction still has to meet the rules of the entry it creates.

The 2026 Nacha fraud monitoring rules and what they require of every ACH participant

Nacha’s 2026 amendments make fraud monitoring an ongoing obligation across originating and receiving institutions. Phase 1 took effect on March 20, 2026, covering large non-consumer Originators, Third-Party Service Providers, or TPSPs, and Third-Party Senders, or TPSs, that met the applicable 2023 annual-volume threshold. ODFIs had to implement enhanced fraud monitoring, while large RDFIs had to implement ACH credit-monitoring controls. The rollout then widened beyond large participants. Phase 2 removed the volume threshold for non-consumer Originators, TPSPs, and TPSs, and brought the remaining RDFIs into scope.

Nacha set Phase 2’s effective date as June 19, 2026, with a practical compliance date of June 22, 2026, because June 19 is a federal holiday. The rules cover entries that are unauthorized or “authorized under false pretenses.” That scope reaches beyond checking whether permission exists. It explicitly includes authorized push payment fraud, business email compromise, and payroll redirection, requiring institutions to consider deception as well as the absence of authorization.

What does “risk-based” permit an institution to decide? It permits greater scrutiny where assessed risk is higher, but not a conclusion that no monitoring is necessary. Nacha does not mandate a particular method or technology. The standardized entry descriptions also support this work by making payment purposes clearer to receiving institutions and account holders. The obligation is therefore an ongoing operational one.

Why ACH's batch architecture creates specific governance gaps when payments are automated or AI-assisted

ACH’s batch architecture was designed for payment files that people created and reviewed. Automated origination changes how instructions are produced without changing the ODFI’s responsibility for transmitting them. That creates an accountability question before any question of speed. Which system generated the entry, under what authority, and with what evidence that authorization preceded submission? A technically valid file does not, by itself, answer those questions.

An automated system that introduces a formatting defect or a mismatch in trailer totals can cause rejection of the whole file. Authorization failures create a different problem because they may become apparent in returns weeks later. By then, remediation is more costly. These are distinct governance gaps, one affecting immediate processing and the other exposing a decision that appeared complete when the file was accepted.

The institution needs an auditable record showing the system version that produced each instruction, the policy it followed, the data it used, and when its authority was granted. Otherwise, the institution may know what it transmitted without being able to explain why the automated system was entitled to generate it. Automation makes that distinction especially consequential because institutional accountability cannot be handed off with the task.

How Same Day ACH and real-time rails change the risk calculus for institutions

Same Day ACH compresses the time available to review instructions by using three processing windows each business day. That speed also intersects with larger potential exposures. Nacha has scheduled an increase in the per-entry limit from $1 million to $10 million on September 17, 2027. A monitoring failure could therefore affect a much larger same-day payment. The governance requirement grows with both the amount at risk and the narrowing opportunity to intervene.

FedNow and the RTP network push that timing pressure further. They settle in seconds, around the clock, make funds immediately available, and produce final, irrevocable payments. ACH’s return-code system and extended return windows do not apply after a real-time payment settles. The distinction is more than a faster timetable. It changes whether a control can still prevent funds from moving or can only identify a problem afterward.

For an institution accepting instructions through voice or text, pre-execution validation must be fast enough for the rail being used. Natural-language instructions from a customer or an AI agent cannot depend on a later review to catch errors before settlement. The IMF’s 2026 note identified risks involving authorization traceability, opaque agent decisions, correlated agent behavior, cybersecurity, and unresolved legal and liability questions. Faster settlement intensifies those concerns. Auditability remains necessary, but an audit record after payment is no substitute for a control before execution.

What banking decision-makers need in place before automating ACH payment operations

For banks and credit unions preparing to automate, authorization integrity should be a deployment requirement. The system must demonstrate that valid authorization existed before each entry was created, with an audit record supporting the ODFI’s obligation. Fraud monitoring must keep running across credits and debits and check for the kinds of deception covered by the 2026 rules. Vendor claims alone are not enough here. The institution needs controls that function as part of payment operations.

Institutions should also require configurable dollar thresholds, counterparty limits, and approval workflows enforced within the automated system. These boundaries should not depend on someone noticing an exception and applying an override. Records need to preserve the decision chain described above, rather than only the resulting instruction, so that the institution can explain its actions to bank examiners. That supports accountability under Nacha’s rules and examination expectations involving fair lending, FCRA, and UDAAP.

Vendor evaluation should treat SOC 2 certification and compliance-readiness as non-negotiable criteria. An institution should require its automation providers to meet the compliance posture expected of the institution itself, because third-party involvement does not erase its exposure. Volume, cost, and competitive pressures make automation increasingly necessary. The decision is therefore not simply whether software can create and submit an ACH file. It is whether the institution can authorize, constrain, monitor, and explain that software’s actions with the same rigor the network applies to processing the payment.