Request access
Invoice & vendor fraudACH fraudAccounts payable fraudCEO & wire fraudAuthorized push payment fraudDeepfake payment fraudTransaction fraud preventionPayee verification, before it settlesBusiness transaction verificationVerifiable attestationVerifiable transaction securityQuantum-safe paymentsAgentic payment securityHow it worksAll payment railsRTP fraud preventionFedNow fraud preventionStablecoin securityTokenized depositsOn-chain settlementBanks & credit unionsFintechs & PSPsStablecoin issuersCrypto custodiansCorporate treasuryMarketplaces & platformsEnterprise transaction integrityWhy RankShield FinancialRankShield vs AccertifyAI-agent payment risksHarvest now, decrypt laterData protectionComplianceSecurityAboutRequest 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.

Request accessVendor payment fraud
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

Isn’t ACH reversible? Why do I need to prevent ACH fraud instead of just reversing it?
The idea that ACH is easily reversible is a consumer protection, and it does not apply to your business the way people assume. A consumer who is debited without authorization has 60 days to dispute it. A business account gets roughly two banking days to return an unauthorized debit under return code R29, because non-consumer accounts do not get the same protections. And on a payment your business originates to a fraudster, for example after a vendor sends fake new banking details, there is no unauthorized-return right at all. The only path is a reversal request limited to genuine errors within five banking days, and it is a request, not a guaranteed clawback. If the money has moved on, it is gone. That is why prevention beats recovery on ACH for a business.
What is the difference between ACH debit fraud and the ACH payments I send?
They are two different exposures with very different recovery odds. ACH debit fraud is someone pulling money out of your account, for example with stolen account and routing numbers. There your bank tools help: an ACH debit block or ACH positive pay can allow or deny incoming debits by rule, and you have a short window to return an unauthorized one. The harder problem is the ACH credits your business sends, to vendors and payroll. If a fraudster convinces your team to send one to the wrong account, you authorized it, so there is no unauthorized-return right and reversal is limited to errors. Most bank fraud tools focus on inbound debits and do very little for the outbound credits where the recovery odds are worst.
How does RankShield prevent ACH fraud?
By verifying the payment before your bank ever originates it, which is the only reliable point of control given how little the rails give you afterward. RankShield verifies the payee against the vendor record you already trust and requires proof that an authorized person approved this specific payment, before it moves. This matters most on the outbound credits where recovery is weakest. It closes the gap that bank tools leave: account validation confirms an account is open, and positive pay filters incoming debits by rule, but neither confirms that the payee on a payment you are about to send is actually your real vendor, and neither proves a genuine human approved it. RankShield does both, automatically, before settlement.
Do the new Nacha rules affect my small business?
Yes, and on a specific date. 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 on March 20, 2026 for larger originators. Phase 2, effective June 2026, eliminates the volume threshold, so it applies to essentially every non-consumer business that originates ACH, no matter how small. The rules are technology-neutral: Nacha requires the outcome, screening for fraudulent payments, not a specific tool. Verifying the payee and the approval before you originate a payment is a direct, documented way to meet that obligation rather than a box-ticking exercise.
I already have ACH positive pay from my bank. Isn’t that enough?
It is a good control for one half of the problem and does nothing for the other. ACH positive pay and ACH debit blocks govern incoming debits: they let you allow or deny who is permitted to pull money from your account, by rule. That is worth having. But they are rule-based allow-and-deny on inbound debits, the rules go stale and need annual review, and critically they do not verify the identity of a payee on a payment you send out. The fraud that hits businesses hardest, the vendor-impersonation payment your own team originates to a fraudster’s account, sails straight past a debit-focused tool. RankShield covers the outbound side positive pay was never built for.
What can you prove, and what are you still building?
The mechanism is real and you can inspect how it works, and we are precise about the rest because a payment-security vendor that overstates its evidence should not be trusted with your payments. We do not claim a large fraud-detection network, since that value comes from many participants and we are early. We do not show you customer names or loss-prevention figures we cannot substantiate. And we do not claim any specific build is cryptographically sealed to our transparency log unless it is, which our transparency page reports honestly. What we offer today is verification of the payee and the approval, before your ACH payment settles, which is the control the rails and the bank tools leave open.
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