Nacha's Account Validation Rule Covers Consumer Web Debits, Not Merchant Settlement, and Even There It Only Asks Whether the Account Is Open. Here Is What Checking a Settlement Account Actually Takes.

Every merchant application carries a routing number and an account number, and every dollar a merchant processes ends up there. Acquiring banks usually pay merchants by ACH credits to the merchant's deposit account at its own bank, and where a third-party processor is involved, the processor usually builds the ACH file. That is how the OCC describes it in its Merchant Processing handbook, last issued in 2014. Processors often debit the same account too. Stripe, for example, can be set to debit a connected account's external bank account to cover a negative balance.

So the settlement account is one of the most valuable fields in the onboarding file, and one of the least examined. Teams often assume Nacha has rules for checking it. Nacha has rules for checking bank accounts, but they are narrower than most people think, and the gaps between them are where settlement fraud happens. This piece sets out what the Nacha Operating Rules require, what each common verification method actually proves, and what a merchant-services team has to decide for itself.

The Validation Rule Most People Have in Mind Does Not Cover Merchants

The rule usually cited is Nacha's WEB Debit Account Validation Rule, effective 19 March 2021. It makes explicit that a commercially reasonable fraudulent transaction detection system for WEB debits must include account validation, on the first use of an account number and whenever the account number changes. WEB debits are consumer debits authorized over the internet. A merchant's settlement deposits, and the fees debited from a business account, are not that.

The rule is still the clearest statement Nacha has made of what validation means, and its own FAQ sets a low floor. At a minimum, the originator must determine that the account is a legitimate, open account to which ACH entries may be posted. Asked whether the rule also requires validating who owns the account, Nacha answers no. It adds that, depending on an originator's business model and risk profile, a more rigorous check that also verifies ownership may be needed to be commercially reasonable.

Nacha's rules are neutral on method. The FAQ lists prenotifications, micro-entries, commercially available validation services from an ODFI or a third party, and API-based validation as examples. It also accepts an account with a proven history of prior successful payments. The one thing it rules out is a fraud detection system with no account validation component at all.

What Each Method Actually Proves

The common methods answer different questions, and for a settlement account the differences matter.

• A prenotification is a zero-dollar entry sent ahead of live entries. Since an amendment in Nacha's 2014 rulebook, which the Treasury adopted for federal agencies in 2017, an originator that sends one may start live entries as soon as the third banking day after the prenote's settlement date, provided its ODFI has not received a return or a Notification of Change. Nacha's FAQ confirms that silence by the end of that window meets the minimum standard: the account is open and can take ACH entries. It says nothing about whose account it is.
• Micro-entries are ACH credits of less than $1, with any offsetting debits, sent to verify an account. Nacha's Micro-Entry Rule, in force since 16 September 2022, requires ACCTVERIFY in the Company Entry Description field and a company name the receiver will recognize, the same as or similar to the one on future entries. Debits must not exceed the credits and must be sent at the same time. Live entries may follow only once the originator's process for checking the amounts is complete, and Nacha says plainly that an unconfirmed micro-entry that simply was not returned does not count. Since 17 March 2023, originators of micro-entries must also run commercially reasonable fraud detection on them, including monitoring forward and return volumes.
• Validation services check the account against data from banks or other sources, often in real time. Some can also return an ownership match. Nacha runs one such network itself, Phixius, which connected to Kinexys by J.P. Morgan in February 2026 and added a fourth data responder in March 2026. Ownership matching is a feature of particular services, not a property of validation in general, so check what a given service returns.

Nacha's own definition of a micro-entry is worth reading closely. It is an entry used to verify a receiver's account or an individual's access to an account. Access is the right word. A person who reads back the two amounts has shown they can see that account. They have not shown the account belongs to the business on the application.

The ACH Network Does Not Check the Name

This is the gap that matters most for settlement. Nacha Rule 3.1.2 says a receiving bank may post an entry relying solely on the account number, regardless of whether the name on the entry matches the name on the account. Nacha restated this in ACH Operations Bulletin #2-2024, which also says receiving banks are not required to perform name matching.

In practice, a settlement credit addressed to a bakery's LLC will post to whatever account the number points at. A prenote to an account a fraudster opened will come back clean. A fraudster who controls the account can confirm micro-entry amounts as easily as a real merchant can. None of these methods catches a bad account number supplied on purpose. Only a check that ties the account to the merchant's legal name or tax ID, or a document from the bank that shows it, does that.

Account Changes Are Where Settlement Goes Missing

Boarding is not the only exposure, and probably not the largest. Once a merchant is live and processing, the account on file decides where real money goes every day, and a change request is the quickest way to redirect it. Stripe's risk guidance for platforms describes the pattern: attackers take over accounts with phished or reused credentials, and Stripe advises platforms to monitor changes to sensitive data, including bank account details, that come from new devices.

Nacha's 2026 risk management rules now speak to this directly. They define False Pretenses as inducing a payment by misrepresenting identity, authority to act for another person, or the ownership of an account to be credited. Since the second phase took effect in June 2026 (19 June on paper, 22 June in practice, because the 19th was a federal holiday), every non-consumer originator, third-party sender and third-party service provider has had to run risk-based processes reasonably intended to identify entries authorized under False Pretenses, and review them at least annually. Nacha's FAQ gives change controls over payment information and instructions for vendor and payroll payments as an example of what an originator might do. A request to send settlement to an account the requester falsely claims belongs to the merchant fits the third part of that definition. If your organization originates settlement credits, or helps originate them, your processes should be built to catch it. Our earlier piece on Nacha's fraud monitoring rules covers the scope in detail.

Two details from the WEB rule's FAQ carry over well as practice, even though the rule itself does not reach settlement. A new account number that has never been used needs validating before first use, even if the old one was validated. A change that arrives as a Notification of Change from the receiving bank does not, because the receiving bank warrants that correction.

What a Merchant-Services Team Should Decide

Nothing in the Nacha Operating Rules prescribes a settlement-account check for merchant boarding. That makes it a policy decision for the acquirer and everyone working under its program. It is worth writing down, because examiners expect controls over the ACH file even when a processor builds it. The OCC's handbook says management should have controls to ensure the ACH transactions are accurate. A reasonable policy covers:

1. What counts as proof at boarding. An open-account check alone, through a prenote or a basic validation response, is the floor. For anything above your lowest-risk tier, decide whether you also need an ownership match against the legal name or tax ID, or a bank letter or voided check you can tie to the business.
2. Micro-entry hygiene, if you use them. Use ACCTVERIFY and a recognizable company name, wait for confirmation rather than silence, and monitor forward and return volumes, which the Micro-Entry Rule requires.
3. A separate, stricter path for account changes. Treat a change to the settlement account as a high-risk event, not a profile edit. Confirm it out of band through a contact already on file, not one supplied in the request. Validate the new account before first use, and consider holding settlement or tightening monitoring for a period after the change.
4. Who owns the decision. In an ISO or payfac model, write down whether the processor, the ISO or the sponsor bank validates the account and approves changes. Gaps open where each party assumes another is checking.
5. Your evidence. Keep the validation result, the method, the date and who approved it in the merchant file. If a settlement credit is misdirected, that record is what shows a reasonable process was followed.

None of this needs new systems for most teams. It needs a decision about what a verified settlement account means, applied the same way at boarding and at every change after it. A few extra minutes on an account change costs far less than explaining to a merchant why its deposit went to someone else.