Prevent unauthorized ACH transfers with bank-authorization controls for small companies

Most unauthorized ACH pulls don't start with a dramatic hack. They start with something boring: a vendor you stopped using two years ago still has your account and routing number on file, nobody set a debit block, and the first time anyone notices the $4,180 withdrawal is when the bank balance comes up short during a Friday reconciliation.

That gap — between "we trust our bank" and "we actually control what can move money" — is where small companies lose cash they never get back. ACH is the quiet one. Wire fraud gets headlines, but ACH debits are easier to initiate, harder to notice quickly, and the return window is unforgiving. Business accounts generally get one business day to return an unauthorized ACH debit (standard return code R29), unlike the 60-day protection consumers enjoy. Miss that window and you're not disputing a charge anymore — you're chasing a vendor for a refund.

This post is a working bank-control setup you can fit on one page: a signatory and authorization matrix, a daily reconciliation quick-check that takes under ten minutes, and an escalation runbook for when something suspicious shows up. Written for the reality of most SMBs — no treasury analyst, one or two people touching the bank, and an owner who finds out about problems after the fact.

If you're tightening ACH controls, you're probably also rethinking how your accounts are structured. Worth pairing this with a look at how to build a covenant-friendly cash structure with proper account maps and sweep mechanics, because segmentation is half the defense.

Why ACH is the exposure nobody budgets for

The mechanical reason ACH is dangerous for small companies: anyone who has ever had your account and routing number can attempt a debit. That's a longer list than most owners realize.

Think about who's touched those numbers:

1. 1
   Every vendor you've ever paid by ACH or set up for auto-debit
2. 2
   The payroll provider you switched away from
3. 3
   The old insurance carrier, the equipment lease you paid off, the software subscription you cancelled by email
4. 4
   Anyone who saw a scanned check (the numbers are printed right on it)
5. 5
   A former bookkeeper or contractor with past access to banking portals

In real operations, the failure usually isn't a sophisticated attacker. It's a legitimate debit that shouldn't still be happening — a cancelled service that keeps pulling, or a vendor who re-ran an old authorization because their system glitched. Those situations blur the line between fraud and error, which is exactly why they slip through. Your bookkeeper sees a familiar vendor name and lets it clear.

The second problem is timing. Most SMBs reconcile monthly, or whenever the close happens. ACH returns are a one-day sport. Monthly reconciliation finds the problem three weeks after your return window closed.

The one-page policy: three parts, nothing fancy

You don't need a 40-page treasury manual. You need three things that fit on a single page and that someone will actually follow.

Part 1 — The signatory and authorization matrix

The core mistake across smaller finance teams is treating "access to the bank" as one thing. In reality there are at least five distinct powers, and the same person usually holds all of them by default. That's the vulnerability.

The non-negotiable rule: no single person should both add a new payee and release the first payment to it. That one separation blocks the most common internal and social-engineering scheme — where a bad actor (or a spoofed vendor email) gets a new account added and money pushed to it the same afternoon.

Set dollar thresholds that match your actual cash flow, not some textbook number. A business doing roughly $80k–$120k monthly in outflows might land somewhere like this:

1. 1
   Under $1,000 — single approver (bookkeeper), reviewed next day
2. 2
   $1,000–$10,000 — two-person approval
3. 3
   Over $10,000 — owner approval required, plus a callback on any new account

One pattern worth flagging: thresholds only work if they can't be gamed by splitting. If your approval kicks in at $10k, someone can run two $6k debits. Your reconciliation quick-check (next section) is what catches the split, so the two parts have to work together.

Part 2 — The daily reconciliation quick-check

This is the part most teams skip because it sounds like a lot of work. It isn't. A focused daily scan of posted and pending bank activity takes under ten minutes once it's a habit, and it's the single highest-leverage control on this list because it collapses detection time from weeks to one day.

1. 1
   Pull pending + posted debits from the bank portal (most banks show both).
2. 2
   Check every ACH debit against a known-payee list. Anything with an originator name you don't recognize gets flagged immediately — not "look into later," flagged now, while the return window is open.
3. 3
   Scan for near-threshold pairs. Two debits from the same originator that sum above an approval limit is a possible split. Investigate.
4. 4
   Confirm amounts match expectations for recurring debits. Your SaaS bill was $290 last month and $1,900 this month? Flag it even if the vendor is legitimate.
5. 5
   Verify no new payees were added since yesterday that you didn't approve. Many bank portals log payee changes — check the audit trail.
6. 6
   Confirm balance moves make sense. An unexplained drop between yesterday's close and today's open is the simplest trip-wire there is.

The piece most people miss: the quick-check isn't about catching everything, it's about catching things while you can still act. A debit spotted on day one can be returned. The same debit found at month-end is a collections problem.

“

Keep a short running known-payee list — just a spreadsheet of legitimate ACH originators with expected amount ranges.

When something falls outside it, you escalate. While you're building this habit, it's also worth running a fee-mapping check to find bank-fee leakage, since you're already staring at line-item bank activity daily.

When something falls outside it, you escalate.

Part 3 — The escalation runbook for a suspected unauthorized transfer

When something trips the scan, the worst outcome is hesitation. People burn the return window trying to figure out who to call instead of acting. The runbook removes that decision. Print it. Tape it near whoever does the daily check.

Escalation steps (run in order, don't skip):

1. 1
   Freeze the question, not your action. The moment a debit looks wrong, treat it as unauthorized until proven otherwise. Don't wait for certainty — you don't have time.
2. 2
   Contact the bank's ACH/fraud line immediately (have the direct number pre-saved, not the general customer line). State you want to return the item as unauthorized and ask the deadline for return code R29 on that specific transaction.
3. 3
   Request a debit block or ACH filter on the originator so it can't pull again tomorrow. This is separate from returning the single item.
4. 4
   Notify the second signatory / owner even if it's after hours. Time beats politeness here.
5. 5
   Document everything — screenshot the transaction, note the time you called, the rep's name, the case number.
6. 6
   If it's a vendor "error" rather than fraud, still return or demand a same-day refund, then fix the underlying authorization so it can't recur.
7. 7
   After resolution, review how it got through. Was a payee added without approval? Was the known-payee list stale? Close that specific gap.

One thing teams consistently get wrong: they call the vendor first to "sort it out" before calling the bank. That's backwards. Sort it out with the vendor after you've protected the return window. The bank clock doesn't pause while you trade emails.

A real scenario

A specialty print shop — around 18 employees and roughly $140k in monthly outflows — had a design-software subscription they cancelled when they switched tools. The vendor's billing system never processed the cancellation and kept pulling $612 a month. For four months nobody caught it. Monthly reconciliation lumped it under "software subscriptions" and the amount looked normal sitting next to their real tools.

They found it only when a new bookkeeper built a known-payee list and noticed the originator didn't match any active vendor. By then they'd lost roughly $2,400, and because the earliest debits were months past any return window, they could only claw back the most recent one through the bank. The rest turned into a refund fight with a vendor who took weeks to respond.

After putting in the daily quick-check and a debit block on inactive originators, a different cancelled vendor attempted a debit about two months later — caught the next morning, returned same day, blocked permanently. Zero loss. The difference wasn't sophistication. It was detection time: weeks versus one day.

When this level of control makes sense — and when it's overkill

This setup makes sense when:

1. 1
   You process recurring ACH debits from more than a handful of vendors
2. 2
   You've changed payroll providers, insurers, or major software in the last two years (old authorizations linger)
3. 3
   One person currently holds all bank powers
4. 4
   Your reconciliation cadence is monthly or slower

This is probably overkill when:

1. 1
   You run a single account with two or three recurring, verified debits and check the balance daily anyway
2. 2
   You've already got hard ACH debit blocks set to allow-list only at the bank, which handles most of the exposure structurally

Who should not try to shortcut this: any business where the owner currently doesn't look at daily bank activity and assumes the bookkeeper "has it covered." That assumption is exactly the condition the controls exist to fix. The daily scan and the second-approver rule only work if they're genuinely split between two people.

Making the debit block do the heavy lifting

If you take one structural move from this entire post, make it this: ask your bank to switch your operating account to ACH positive pay / debit filtering set to allow-list mode. Instead of blocking fraud after it happens, you pre-approve which originators can pull at all. Everything else gets rejected automatically.

Most banks offer this. Most SMBs never turn it on because nobody told them it exists. It changes the entire posture — your daily quick-check becomes a scan for approved activity that looks wrong, instead of hunting for unapproved activity hiding in plain sight. The allow-list handles the first line of defense, and you're just verifying amounts and watching for new payee requests.

The one maintenance cost: every time you onboard a legitimate recurring vendor, you add them to the filter. That's roughly a five-minute task, and it's the right kind of friction — it forces a deliberate decision every time something new gets permission to pull from your account.

Keeping the policy alive

A one-page policy dies the moment it becomes a file nobody opens. A few things keep it real:

1. 1
   Review the known-payee list monthly. Remove cancelled vendors the same day you cancel them, not eventually.
2. 2
   Re-verify the signatory matrix whenever someone leaves. A departed bookkeeper with lingering portal access is a textbook exposure.
3. 3
   Dry-run the escalation runbook once. Call the bank's fraud line and confirm the number works and you know the return deadline before you need it at 4:45 on a Friday.
4. 4
   Log every flagged item, even the false alarms. The pattern of what trips the scan tells you where your real risk actually sits.

None of this requires a treasury specialist or expensive software. It requires that someone looks at the right slice of bank activity every day, that no single person can both invite a new payee and pay them, and that when something looks wrong, there's a printed set of steps that beats the ACH return clock. Unauthorized ACH pulls aren't usually a security failure — they're a timing failure. And timing is the one thing a daily habit and a clear runbook actually fix.

None of this requires a treasury specialist or expensive software. It requires that someone looks at the right slice of bank activity every day, that no single person can both invite a new payee and pay them, and that when something looks wrong, there's a printed set of steps that beats the ACH return clock. Unauthorized ACH pulls aren't usually a security failure — they're a timing failure. And timing is the one thing a daily habit and a clear runbook actually fix.