ACH origination agreement template, clause by clause

An ACH origination agreement template is the contract a bank uses when a business client starts sending ACH payments through it, and it should contain, at a minimum: the entry classes the client may originate and the company ID it will use; daily credit and debit exposure limits, with what happens over them; the client's duty to obtain and keep receivers' authorizations; the bank's right to audit and to receive financial information; fines, termination and reversals; who monitors for fraud under the 2026 Nacha rules; and the security procedure the client accepts, with any stronger procedure it refuses, in writing. The template is hard to get right because each clause carries a different body of law, the Nacha Rules, OCC and FFIEC guidance and UCC Article 4A, and because a clause that fails is found only after a loss. Botminds' Treasury Management Onboarding reads the signed agreement and schedules and drafts the client's setup from them, each value citing its page.

The examples come from a fictional sample client, Halvorsen Freight Systems, whose ACH Origination Schedule a fictional bank's agents read in the solution. This page explains what the rules and cases require; it is not legal advice, and a bank's counsel should draft the clauses to its state's version of the UCC.

What must an ACH origination agreement include?

An ACH origination agreement must cover what the examiners look for and what the rules make the bank answerable for. The FFIEC's examination procedures ask whether "agreements between the ODFI and originators adequately address - Liabilities and warranties, - Responsibilities for processing arrangements, and - Other originator obligations such as security and audit requirements", whether written agreements "require the submission of periodic financial information", and whether they "address exposure limits" (FFIEC IT Handbook, Retail Payment Systems, Appendix A). The OCC's underwriting standards for originators fill in the rest.

A template is usually two layers: a master agreement with the legal terms (the treasury management master services agreement covers that layer and its amendments), and a product schedule per service with the operating values, the company ID, permitted classes, cut-off, limits and prenote rules. The schedule is the part implementation teams configure from, so it is also the part most worth getting exactly right.

Does an originator have to sign an agreement with the bank?

Yes: a business that originates directly through a bank does so under an agreement with it. The FFIEC's glossary defines the originating bank as one that "originates entries at the request of and by agreement with its originators in accordance with the provisions of the NACHA rules" (FFIEC IT Handbook glossary).

The exception proves the point. When a payroll processor or other third-party sender sits between the bank and the originator, the OCC notes that the bank then has no contract with the originator at all, which is exactly why third-party senders need their own, stricter agreements and oversight (nested third-party sender examples quotes the OCC and shows the layers). A treasury client that sends its own files signs the origination agreement itself.

Permitted SEC codes, the company ID and the descriptions

The permitted-classes clause should name each Standard Entry Class the client may originate and, ideally, what each is for. "PPD and CCD" is a permission; "PPD for payroll to employees' accounts, CCD for payments to suppliers' business accounts" is a permission the bank can test against. Nacha's risk group lists "an SEC code that is not permitted in the customer's origination agreement" among the anomalies exposure limits exist to catch, and notes that banks may limit SEC codes to match an originator's expected business needs (Nacha, RMAG Originator Essentials).

The same schedule should state the company ID the bank has assigned and the Company Entry Descriptions the client will use, including PAYROLL for wage credits. Two of the ways a new client's first file fails trace back to this clause: a company ID left over from the previous bank and a vendor batch coded PPD. A schedule that states both clearly turns each into a one-line fix.

What is an exposure limit in an origination agreement?

An exposure limit is the maximum the client may originate, set by the bank's credit function and written into the agreement or its schedule with what happens above it. The FFIEC's glossary defines it as the most an originator may send, sized from its credit standing, its past or expected funding needs and the type of payment; how to calculate an ACH exposure limit works the number out for a sample originator. The clause should state separate daily credit and debit limits, how they apply across settlement dates, and what the bank will do with a file that would breach them.

The overlimit clause matters as much as the number. The OCC asks banks to "establish overlimit monitoring and approval" and to make sure "approvals of over-limit transactions are well controlled and consistent with the bank's policies for extending unsecured credit." A good clause says the bank may hold an overlimit file, will contact named client contacts, and may require prefunding before releasing it. It also gives the bank the right to change the limit, because the examiners check that a rise in an originator's debit returns triggers a re-evaluation.

Prefunding is not a limit

Many banks require prefunding for some or all credit files and treat that as a substitute for an exposure limit. Nacha's risk group says plainly that it is not: prefunding is no exposure limit, and it controls neither fraud nor returns (Nacha, RMAG Originator Essentials; what ACH prefunding means quotes it and sets out when prefunding fits). Prefunding protects the bank if the client cannot pay for its credits. It does nothing if a fraudster in the client's system sends large credits from a funded account, and nothing about returned debits.

The template should therefore carry both: prefunding where the credit decision calls for it, and limits in every case. The sample client's agreement shows the pattern. It asked for $1,200,000 of daily credit; the credit officer approved $900,000, about 2.2 times the client's largest measured day, and a $250,000 debit limit against $750,000 requested, because the client sends no debits at go-live.

The limit in the schedule, approved by a named person with its review dates

Can the bank audit an originator?

Yes, if the agreement says so, and the OCC expects it to. Its underwriting standards include the bank's right to "audit originators' ACH processes and controls at the bank's discretion", and the FFIEC's procedures check that agreements require "periodic financial information." Without the clause, a bank that sees rising unauthorized returns or an unusual pattern of entries has no contractual way to look.

Two details make the right usable. The clause should name what the bank may see, including authorizations, since "the burden of proof for Authorization is on the Originator," and how quickly the client must produce it. And it should tie financial reporting to the credit review, so the limit can be revisited on fresh numbers rather than on the statements the client gave at onboarding.

Fraud monitoring after June 2026: who does what

Since phase 2 of Nacha's fraud-monitoring rules, dated June 19, 2026 and effective in practice on June 22, every non-consumer originator must run risk-based processes to identify entries that are unauthorized or authorized under false pretenses, and review them at least annually; the bank must do the same as ODFI. Nacha's FAQ lets one participant's processes rely on another's when the allocation is clear, and suggests what an originator is best placed to do: control changes to vendor and payroll payment instructions (Nacha, Fraud Monitoring Phase 1 FAQs; payroll diversion shows why that control matters).

The agreement is where that allocation should live. A clause that says the client will maintain change controls over payee and payroll instructions, review them yearly and tell the bank of suspected fraud promptly makes the client's obligation concrete. Nacha's rules state that they do not change who bears losses: the FAQ says expressly that they leave Article 4A rights and obligations as they were (the 2026 Nacha fraud monitoring rules quotes the disclaimer). Loss allocation still comes from the law and the agreement, which brings the template to its most consequential clause.

The security procedure clause, and the refusal clause

Article 4A lets a bank shift the loss on an unauthorized payment order to its customer when the two have agreed a commercially reasonable security procedure and the bank followed it in good faith (UCC § 4A-202(b)). A security procedure is "established by agreement" and can involve codes, encryption or "callback procedures"; a signature comparison alone does not count (UCC § 4A-201). The template therefore needs a clause describing the procedure, and a second one for the procedures the client declined.

The leading case on that second clause is Choice Escrow v. BancorpSouth. The bank offered dual control on online wires; the customer declined it in a signed waiver, and declined daily transfer limits as well. When a fraudster used a compromised employee login to send $440,000 abroad, the court held the bank's package of passwords, offered transfer limits, device authentication and offered dual control commercially reasonable (8th Cir. 2014; entitlements in banking quotes the waiver finding).

"The loss of funds from Choice's account falls on Choice."

Choice Escrow & Land Title, LLC v. BancorpSouth Bank (8th Cir. 2014)

The signed waiver did the work. Without it, the bank would have been arguing about what it had offered, and the customer about what it had understood.

A clause that holds, and one that fails

Not every loss-shifting clause survives. Article 4A lets the bank, "by express written agreement", limit how far it enforces a verified order (UCC § 4A-203(a)(1)), but it also says that rights and obligations under §§ 4A-202 and 4A-203 "may not be varied by agreement" except as those sections allow. A template that tries to put every unauthorized wire on the customer, whatever the procedure, reaches past what the code permits.

How Treasury Management Onboarding reads the signed agreement

A template earns its keep when the signed version drives the setup. In Treasury Management Onboarding, the Setup agent reads the signed proposal and each product schedule and drafts every setup field from them, citing the schedule and page beside each value. For the sample client's ACH Origination Schedule that meant the company ID and the permitted classes from page 2, the cut-off and funding method from page 3, prenotes and reversals from page 4.

The exposure limit, decided on what the client will actually originate

Because each value points to its clause, a second implementer can check the configuration against the signature rather than against a template, and an auditor can trace any setting back to the page the client signed. Where the schedule is silent or ambiguous, the drafted field is held for a person. For the order in which the agreement, the limit and the signed security procedure must be in place, see the treasury management checklist before go-live; the solution is at Treasury Management Onboarding.

Questions people ask

Is there a Nacha ACH origination agreement template?

The origination agreement is the bank's own contract; the public Nacha pages cited here say what it must support rather than supplying the text. Nacha does publish a sample authorization form for consumer debits, which is the receiver's authorization, not the bank's agreement with the originator.

What are the ACH origination agreement requirements examiners check?

The FFIEC procedures ask whether agreements address liabilities and warranties, processing responsibilities, security and audit obligations, periodic financial information and exposure limits. The OCC adds permitted entry classes, overlimit approval, prefunding or collateral, termination and the right to audit.

Is prefunding an exposure limit?

No. Nacha's risk group is explicit that prefunding neither replaces an exposure limit nor controls fraud or return risk (ACH prefunding meaning sets out when to require it). It protects the bank against a client that cannot pay for its credits; limits are still needed for fraud, errors and duplicates.

Can a bank pass Nacha fines on to an originator?

Nacha assesses fines to financial institutions, and its risk group notes that institutions may contractually pass them on to originators. Fines can reach $500,000 a month for egregious violations, so the pass-through clause is worth stating explicitly.

What should an ACH origination agreement say about dual control?

It should say whether dual control applies, and if the client declines it, record the offer and the refusal with the client's written agreement to be bound by orders accepted under its chosen procedure. That is the written agreement Article 4A requires, and the signed waiver was decisive in Choice Escrow.