Request access
RankShield Financial · ACH

ACH fraud preventionfor the payments your bank won’t reverse.“ACH is reversible” is a consumer protection. Your business gets about two banking days on a fraudulent debit, and no return right at all on a payment you send to the wrong account. On ACH, for a business, prevention is most of what you get.

payee-verifiedapproval-provenbefore origination
Your real ACH return window
~2 days
a business gets ~2 banking days to return an unauthorized ACH debit (code R29). Consumers get 60 (EPCOR / Nacha)
0
return right on an ACH credit you originate to a fraudster. Only a limited, non-guaranteed error reversal within 5 days
01 // the myth
The reversibility myth

ACH protections you have heard about are for consumers

The internet says ACH can be clawed back. For your business, that is mostly not true, and the exceptions are short.

The belief that an ACH payment can be undone comes from consumer banking, where someone debited without authorization has 60 days to file a dispute. Business accounts do not get that. Under the ACH rules a company has roughly two banking days to return an unauthorized debit, using return code R29, and as the payments association EPCOR puts it plainly, non-consumer accounts do not have the same protections as consumer accounts. Most small businesses do not reconcile their account inside two banking days, so the window is often gone before anyone notices.

The harder case is the money your business sends. When you originate an ACH credit to a vendor and it turns out the banking details were a fraudster’s, you authorized that payment, so there is no unauthorized-return right. The only recourse is a reversal, and under Nacha’s rules a reversal is permitted only for a genuine error, a duplicate, a wrong payee, or a wrong amount, and must be sent within five banking days. Even then it is a request, not a clawback. If the receiving account has been emptied, the money does not come back. The FBI’s own rapid-recovery team succeeds on about 66 percent of the cases it can act on, and only when fraud is reported fast, which tells you how unreliable after-the-fact recovery is.

02 // two directions
Debit in, credit out

ACH fraud has two directions, and the odds are worst on the one your bank ignores

Debit in
Someone pulls money from your account. Bank tools help: ACH debit block and positive pay allow or deny incoming debits by rule, plus a short return window.
Credit out
Your team sends a payment to a fraudster's account. You authorized it, so there is no unauthorized-return right and recovery is a limited error reversal at best.
The gap
Bank tools focus on inbound debits. The outbound credit, where recovery is weakest, is exactly where verifying the payee before you send is the only real control.
03 // how it lands
The payment you can’t get back

A vendor ACH to the wrong account

Payroll or a vendor batch is due, and the bank details ‘changed’

Your team originates an ACH credit to a fraudster

A supplier or an internal request updates the account for the next ACH run. The batch goes out. Because your business authorized the credit, there is no unauthorized-return right, and a reversal only applies to a clear error inside five banking days. By the time it is caught, the receiving account is drained.

RankShield: RankShield verifies the payee against the record you already trusted and requires proof an authorized person approved this batch, before your bank originates it.
04 // on a clock
Why now

Nacha now requires you to screen for fraudulent payments

This stopped being optional, and Phase 2 pulls in businesses of every size.

Nacha’s risk-management rules require businesses that originate ACH payments to run risk-based processes to identify payments initiated through fraud. Phase 1 took effect March 20, 2026 for larger originators. Phase 2, effective June 2026, removes the volume threshold, so it reaches essentially every non-consumer business that originates ACH, regardless of size. The rules are deliberately technology-neutral: Nacha requires the outcome, screening payments for fraud, and leaves the method to you. Verifying the payee and the approval before you originate is a direct way to satisfy that, and it happens to be the control the rails leave open.

How this maps to compliance
05 // the fix
What the bank tools miss

Account validation proves an account is open, not that the payee is real

Every ACH control you already have governs inbound debits or confirms an account exists. None verify the payee on a payment you send.

Debit block / positive pay

inbound only

Allow or deny incoming debits by rule. Worth having, but rule-based, needs annual review, and does nothing for the outbound credit where recovery is worst.

Account validation

open ≠ real

Confirms an account number is open at the receiving bank. A fraudster’s own open account passes. It does not confirm the account belongs to your real vendor.

Payee verification

who they claim

RankShield checks the payee against the vendor record you already trusted, before you originate. The step none of the above performs.

Proof of approval

a real human

The payment carries proof an authorized person approved this specific batch. Dual control that a spoofed email cannot forge past.

Shared across the network

flagged once, known to all

A payee or account flagged at one member of the RankShield Network is shared across it, so an account used against another business is known before you originate to it. Unlike a scoring consortium, every shared verdict is independently verifiable, and the signal compounds as members join.

What we claim, and what we do not

Straight about the rails, and about ourselves

We will not tell you ACH is irreversible like a wire, because it is not: consumers get 60 days and businesses get a short window on debits. What we will tell you is that on the payments your business sends, recovery is unreliable, so verifying before you originate is the control that matters. And we do not claim a fraud network, customer names, or a sealed build we cannot show you, which our transparency page reports honestly.

FAQ

ACH fraud, answered

Every question buyers ask before they trust a payment-security platform, answered directly.

JAMIE KLONCZ · RANKSHIELD FINANCIAL ONLINE

Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it.

REQUEST ACCESS →
Verify, then settle

See your payments verified before they settle.

ACH gives a business almost nothing back once a payment leaves. Verify the payee and the approval before it settles, on every ACH you send. Request access and we will map it to your payment process.

Request accessHow it works