Is pay by bank secure for US businesses?
Payments
October 9, 2026
|
Aeropay Team
This article was written by the payments nerds at Aeropay. Our goal is to provide you with solid insights to help your business operationalize more efficient, value-focused payments.
Pay by bank asks customers to connect the account their paycheck lands in, which is a bigger ask than typing in a card number. Merchants have a fair question of their own: who carries the risk when a payment goes wrong?
Yes. Pay by bank is secure for customers because they approve each connection by logging in with their own bank, so the merchant never handles a password or a reusable card number. The merchant's exposure is ACH returns. A consumer's bank has 60 days from settlement to return a debit the consumer didn't authorize, so account verification and fraud screening determine the real risk.
The merchant's protection comes from checks that run before funds move. Nacha now requires every business that originates ACH payments to run fraud monitoring, under rules that took full effect in June 2026.
The customer logs in to their own bank, and the bank sends back a secure token in place of the password. The merchant never sees the customer's banking login, and the customer never types a card number into the checkout page.
The customer picks their bank at checkout, logs in on the bank's own screen, and approves the connection. The token lets the payment provider confirm the account and initiate the payment.
That design removes the asset fraudsters target at card checkout. A stolen card number works at any merchant until the issuer cancels it. A bank token is issued for one connection, and the bank or the customer revokes it without changing the account.
The account number still needs protection once it is stored. Nacha requires non-financial originators and third-party senders with at least 2 million ACH payments a year to render account numbers unreadable when stored, using methods such as encryption, tokenization, or truncation. A merchant that lets its pay by bank provider store and tokenize account data keeps the number out of its own systems entirely.
The main risk is the ACH return, where the customer's bank sends a completed payment back after the merchant has already delivered. Card fraud surfaces as a chargeback. Pay by bank fraud surfaces as a return, and the return code tells the merchant what went wrong.
Return windows from EPCOR's return reason code resource; limits from Nacha's Risk and Quality Rules fact sheet.
Those limits carry consequences. When an originator's unauthorized return rate passes 0.5%, its bank must give Nacha a plan to bring the rate back under 0.5% within 30 days.
Every business that originates ACH payments must now run risk-based procedures to identify payments that are unauthorized or induced by fraud, and review those procedures at least once a year. Nacha's fraud monitoring rules reached all non-consumer originators on June 22, 2026, regardless of volume.
Phase 1 took effect March 20, 2026, for all originating banks and for originators and third-party senders above 6 million entries in 2023. Phase 2 removed the volume threshold.
Nacha leaves the method to each business. Nacha does not require merchants to screen every payment individually or to monitor before processing, though it notes that monitoring before processing gives the best chance of stopping fraud. For debits, Nacha treats a working return and return-rate monitoring program as the minimum.
Two older rules sit underneath the new ones. Since March 19, 2021, merchants that collect debits authorized online must validate the account number before its first use and after any change to it. Nacha does not count a fraud detection system as sufficient unless it includes account validation.
A merchant does not have to build all of this in-house. Nacha lets originating parties rely on another participant's monitoring, such as a payment provider's, when the split is set by contract and verified through oversight. What counts as compliant depends on the role a business plays in each payment, so confirm the allocation with your bank and provider.
A provider should verify the account, check the live balance, and score each payment for fraud and return risk in real time, all before the debit is sent. Checks that run after settlement only explain a loss. Checks that run before it prevent one, and each check maps to a specific return type.
We built Guard, our risk-prevention product for bank payments, to score each transaction in real time and predict fraud and return risk before funds move. Guard learns what normal behavior looks like for each merchant's users and flags payments that drift from that baseline. When Guard's model rejects a payment, the merchant receives a specific reason code (balance-related, risk-score-related or uncategorized) instead of a generic decline. Guard pairs AI models with human fraud analysts, and merchants can reach Aeropay's fraud team directly about emerging threats.
Security and conversion pull against each other at checkout. A risk model that declines too much protects the return rate and loses good customers, so the number to ask any provider for is its approval rate alongside its return rate. Across merchants, Aeropay's average payment approval rate is 90% or higher with real-time risk decisioning.
A subscription business keeps unauthorized returns down by collecting a precise authorization and checking each debit before it runs. The payment method itself holds up well for recurring billing, since a linked bank account doesn't expire or get reissued the way a card does.
The risk comes later, from disputes. Take a gym membership, the example Nacha uses to explain it. A member checks their statement in July and spots six months of charges they say they never signed up for. Their bank sends back every debit that settled in the last 60 days, and that money comes out of the gym's account. A subscription business that bills monthly carries about two months of payments in exposure per customer at any time.
Write the authorization so it states the amount, the schedule, and how to cancel. A debit that departs from those terms, such as a wrong date or amount, gives the customer's bank grounds to return it as R11, and that return counts toward the 0.5% unauthorized limit.
Check the balance before every scheduled debit as well as at signup. A balance check at the moment of billing catches the insufficient-funds return that a signup check can't see.
Schedule debits around the customer's pay cycle and retry failed ones when funds arrive. An immediate retry hits the same empty account, while a retry timed to the next deposit has funds to clear.
The merchant does, unless a provider guarantee that includes unauthorized returns covers the payment. The consumer's bank returns the debit, and the funds come back out of the merchant's account through its own bank.
Yes, up to twice. Nacha allows a debit returned for insufficient or uncollected funds (R01 or R09) to be reinitiated a maximum of two times, within 180 days of the original settlement date.
No. PCI DSS governs card data, and a pay by bank payment carries none. Bank account numbers fall under Nacha's ACH data security rules instead, and a merchant that also accepts cards keeps its PCI obligations for those payments.
Request a payment assessment, and we'll map your return rates by type to the checks that target each one.