ACH can be a practical way to pay vendor invoices, but bank-account changes are a fraud target and account data is sensitive. The controls depend on whether you are sending a credit to a vendor or initiating a debit from an account.
This guide focuses on U.S. business-to-business vendor payments sent as ACH credits. Your financial institution's ACH origination agreement and the Nacha Operating Rules govern the exact process, so confirm requirements with the bank or payment provider.
Start With the Entry Type
An ACH credit sends money from your account to the vendor's account. An ACH debit pulls money from the receiver's account. Consumer-debit authorizations have detailed rules that should not be copied wholesale into a business-vendor credit workflow.
For vendor credits, collect documented payment instructions, confirm the recipient, and satisfy the controls in your origination agreement. If your workflow also originates debits, obtain entry-specific advice from your financial institution because the authorization form, Standard Entry Class code, proof, and retention rules can differ.
Nacha requires authorization for ACH entries, but the minimum requirements vary by receiver type, entry type, channel, and Standard Entry Class code. A blanket claim that every vendor credit needs the same signed form retained for two years is inaccurate.
What to Collect for Vendor-Payment Instructions
Use a form or secure workflow that captures the information your financial institution and internal controls require. Common fields include:
Account holder name. The legal name on the bank account, which may differ from the vendor's business name.
Routing number. Validate format, then use an authoritative routing-number source or your payment provider's validation. A check-digit test can catch some malformed numbers, but it does not prove the account exists or belongs to the vendor.
Account number. The account number at the specified bank. Confirm it once.
Account type and transaction context. Capture the fields required by the bank or provider for the entry you will originate.
Payment direction and purpose. State that the instructions are for vendor payments by ACH credit. Do not add debit authority unless the business process genuinely needs it and the applicable authorization rules are satisfied.
Attestation and date. Capture who supplied the instructions, their role, when they supplied them, and any approval your bank or policy requires. A signature alone does not prove account ownership or authority.
Company information. Your company name should appear in the authorization so there is no ambiguity about who is authorized to initiate transactions.
Verify New and Changed Instructions
Treat a request to change vendor banking details as a high-risk event. Nacha identifies vendor impersonation and business-email compromise as false-pretenses scenarios in ACH payments. Use controls such as:
- Verify the change through a trusted contact and channel already on file, not the contact details in the change request
- Separate the person who enters a change from the person who approves it
- Apply risk-based review or a payment hold before a material first payment to changed details
- Keep evidence of the request, verification, approval, and effective time
Nacha's rules also require some ACH participants to implement risk-based processes and procedures reasonably intended to identify entries initiated due to fraud. Confirm the rules and effective dates that apply to your organization with your ODFI.
Supporting Evidence Is Not Proof by Itself
Some companies request a voided check or bank letter. These can help transcribe details, but an image can be altered and does not independently establish that the requester is authorized. Use it as one input to a layered verification process.
How to Store ACH Data Securely
ACH data is sensitive by any standard: it contains bank account numbers that can be used to initiate fraudulent transfers. Storage requirements:
Render account numbers unreadable at rest where the Nacha rule applies. Nacha allows approaches such as encryption, truncation, tokenization, destruction, or financial-institution-hosted storage; it does not mandate one cipher such as AES-256. Even outside the rule's volume threshold, protecting account numbers is a sound control. See OnComply's security overview for product-specific practices.
Restrict access. Only team members who need ACH data to perform their job should be able to access it. This typically means finance team members with an operational need, not the full company or anyone with database access.
Access logging. Log access and changes according to your risk, security, and audit requirements.
Masking for display. Show only what users need. Require stronger authorization before revealing full account details when your risk model calls for it.
What to Do When Banking Information Changes
When a vendor changes bank details, obtain new documented instructions and complete the verification and approval process before using them.
Make vendor banking information changes part of your formal change management process: new authorization collected, verified, and approved before the AP system is updated. The finance team's guide to vendor payment compliance covers the controls this feeds into.
Document every change with a timestamp and the identity of the person who made the update. Bank account changes are a common vector for payment fraud, whether from an external attacker who has compromised the vendor's email or an insider at the vendor.