OpenClearCheck positive pay compares each presented check with a list of checks the customer actually wrote. ACH positive pay compares each incoming ACH debit with rules saying who is allowed to debit the account. The first is a list of items; the second is a list of permissions. That one difference drives everything else: setup, timing, exception reasons and how items are returned.
Side by side
| Check positive pay | ACH positive pay | |
|---|---|---|
| What the customer provides | An issue file for every check run: account, check number, amount, date, often payee | Authorization rules, set once and maintained: which originators (by Company ID) may debit which accounts |
| What's compared | Each presented check against the matching issue record | Each incoming debit against the rules for that account |
| Typical limits | Exact amount; payee; void, stop and stale-date status | Maximum amount, how often in a period, permitted SEC codes, and optionally a specific receiver ID |
| Credits | Not applicable | Usually not filtered; money coming in isn't the risk |
| Source of presented items | Image cash letters and on-us items | Incoming ACH files |
| How a return happens | Check return, normally an image return, with a return reason | An ACH return entry with a Nacha return reason code |
| The deadline that drives the cutoff | The paying bank's midnight deadline under the UCC, and Regulation CC's expeditious-return requirements | The Nacha Rules' return timeframe for the reason code used |
How ACH positive pay works
Every ACH batch carries a Company Identification number for the originator, a Standard Entry Class (SEC) code such as CCD, CTX, PPD or WEB, and an amount and effective date for each entry. ACH positive pay products let a business customer say, account by account:
- Block all debits. Common on accounts that should never be debited, like a payroll funding account.
- Allow listed originators. The utility, the payroll processor and the tax authority, each by Company ID.
- Limit each authorization. A maximum amount per debit, a maximum number of debits per period, and the SEC codes permitted.
- Narrow it to one receiver. Allow an originator in general, but apply tighter limits when the debit carries a specific receiver or individual ID.
Industry terms vary. "ACH debit block" usually means block everything. "ACH debit filter" means allow only what's on the list. "ACH positive pay" is commonly the filter plus a review step, so a debit from an unknown originator goes to the customer as an exception instead of being returned automatically. The review step matters because legitimate new originators show up all the time: a new vendor, a new insurer, a tax payment.
A good ACH positive pay workflow lets the customer turn an exception into a standing rule in one step. "Pay, and always allow this originator up to this amount" saves the next month's exception.
Timing is tighter for ACH
For checks, the paying bank must return a check, or send notice of dishonor, before its midnight deadline: midnight of the banking day after the day it received the item. Customer cutoffs are set earlier than that so the bank can build and send its returns.
For ACH debits to business accounts, the usual return reason for a debit the customer didn't authorize is R29 (Corporate Customer Advises Not Authorized). It has a short return window: the return generally must reach the originating bank by the opening of business on the second banking day after settlement. Consumer accounts have longer windows for unauthorized returns, backed by a Written Statement of Unauthorized Debit. ACH positive pay is mostly a business-account product, so that two-day window sets the pace. Check the current Nacha Operating Rules for exact requirements; they change, and the details matter.
Common exception reasons
| Check exceptions | ACH exceptions |
|---|---|
|
|
Which does a business need?
Usually both. A business that writes checks needs check positive pay, ideally with payee matching. Any business account with a published account number, which means any account that writes checks, can also be debited by anyone who has that number. Account takeover and fraudulent debits using numbers lifted from a stolen check are exactly what ACH filters stop. Banks often bundle the two for that reason.
Running both in one place
Many banks run check and ACH positive pay on separate systems, sometimes from separate vendors, with separate customer screens and separate exception reports. That doubles onboarding and gives reviewers two queues with two cutoffs. OpenClear treats each payment network as a plug-in to one shared exception and decision core. Checks and ACH debits land in the same queue, with the same dual-control, audit trail and notification rules, and each keeps its own matching rules and deadlines. It also reads standard NACHA files, with control totals checked, so incoming ACH can be loaded directly. See the architecture docs for how the network adapters work.
Whether you're evaluating OpenClear or working through a positive pay project, get in touch.