9 min readWhat ACH Authorization Requirements Must Your Fintech App Meet?
If you're building a fintech app that processes ACH debits, you're legally required to obtain proper authorization before pulling money from a customer's bank account. NACHA (the National Automated Clearing House Association) sets strict rules about what constitutes valid authorization, what information you must collect, and how long you need to retain proof. Getting this wrong exposes you to customer disputes, financial liability, and potential removal from the ACH network.
This post walks through exactly what your fintech app needs to collect and store to meet ACH authorization requirements.
What Information Must Be Included in ACH Authorization
Every ACH authorization must contain specific data points to be considered valid under NACHA rules. Your app needs to collect and store all of the following:
Customer information:
- Full legal name
- Billing address
- Phone number (recommended but not always required)
Bank account details:
- Bank routing number (9 digits)
- Account number
- Account type (checking or savings)
Payment details:
- Payment amount (or statement that it will vary)
- Payment frequency (one-time, recurring, or on-demand)
- Payment date or schedule
- Clear statement that this authorizes ACH debits
Authorization proof:
- Date and time of authorization (timestamp)
- IP address of the customer (for online authorizations)
- Method of authorization (web, phone, paper)
The authorization must clearly state that the customer is authorizing ACH debits from their account. Vague language like "I agree to pay" is not sufficient. Use explicit phrasing such as "I authorize [Your Company Name] to electronically debit my account."
Valid Methods for Obtaining ACH Authorization
NACHA recognizes several methods for obtaining customer authorization, and each has specific requirements for proof retention.
Written authorization is the traditional method where customers sign a physical or digital document. For digital signatures, you must retain the signed document with a verifiable signature. DocuSign, Adobe Sign, and similar e-signature platforms that meet ESIGN Act requirements are acceptable.
Telephone authorization requires that you record the call or send written confirmation to the customer within a specific timeframe. If you record the call, it must capture all required information fields and explicit verbal consent. If you don't record calls, you must send written confirmation to the customer and give them a period to object before processing the first debit.
Online or mobile authorization (WEB entries) is the most common method for fintech apps. You must display all required information on screen before the customer submits. You must capture and retain the customer's IP address and the exact timestamp of authorization. The customer must take an affirmative action like clicking "I Authorize" or checking a box, not just passively accepting terms buried in a user agreement.
Standing authorization for recurring or variable payments requires clear disclosure that amounts and dates may vary, and you must notify customers of upcoming debits if they exceed a specified threshold or differ from the regular pattern.
Account Validation Requirements
Authorization alone is not enough. Before processing the first ACH debit, you must verify that the bank account is legitimate and open using a "commercially reasonable" method.
The most common validation methods are:
Micro-deposits: Send two small deposits (typically under $1 each) to the account and require the customer to verify the exact amounts. This confirms the customer has access to the account.
Instant verification APIs: Services like Plaid, Yodlee, or Finicity let customers log into their bank account through your app to verify ownership instantly. This method is faster and has higher completion rates than micro-deposits.
Pre-note transactions: Send a zero-dollar ACH transaction to verify the account exists and can receive ACH transactions. The receiving bank will reject the pre-note if the account is closed or invalid.
You must complete account verification before processing the first debit. Processing debits to unverified accounts significantly increases return rates and puts you at risk of NACHA penalties.
How Long Must You Retain Authorization Records
NACHA requires you to retain proof of authorization for as long as the authorization remains in effect, plus two years after the last transaction. If a customer disputes a transaction, you must be able to produce the original authorization to defend against the claim.
For recurring payment authorizations, this means you might need to retain records for several years. If a customer authorized monthly payments in 2024, canceled in 2026, you must keep that authorization record until at least 2028.
Store these records in a secure, tamper-proof system. If you cannot produce valid authorization when challenged, you will likely lose the dispute and be required to return the funds to the customer. Multiple failures to produce authorization can result in fines or removal from the ACH network.
Include in your retention system:
- The complete authorization record with all required fields
- Timestamp and IP address (for online authorizations)
- Any confirmation emails or notices sent to the customer
- Records of account verification
- Transaction history associated with that authorization
Common ACH Authorization Mistakes to Avoid
Burying authorization in terms of service. Your terms and conditions cannot serve as ACH authorization. Authorization must be a separate, clear action where the customer explicitly consents to debits from their specific bank account.
Failing to update authorization for scope changes. If the payment amount, frequency, or timing changes materially from what the customer authorized, you need new authorization. You cannot start charging weekly instead of monthly, or double the payment amount, under the original authorization.
Not capturing required proof elements. Missing IP addresses, timestamps, or other required data points means you don't have valid proof. If you're building the authorization flow yourself rather than using a payment processor's hosted solution, audit your implementation to confirm you're capturing everything.
Processing debits before account verification completes. The temptation to speed up onboarding by processing payments immediately is strong, but unverified accounts have much higher return rates. A returned transaction typically costs you $2-5 in fees plus the lost payment amount.
Using pre-checked boxes or implied consent. The customer must take an affirmative action. A pre-checked "I authorize" box does not meet NACHA requirements. Neither does language like "by continuing, you agree."
Implementation Approaches for Your Fintech App
If you're building ACH functionality from scratch, you have two main paths: integrate with a payment processor that handles authorization, or build authorization collection yourself while using a processor just for payment movement.
Using processor-hosted authorization is the lower-risk path. Stripe, Dwolla, Modern Treasury, and similar processors offer hosted authorization pages or embeddable components that collect all required information, handle validation, and store proof. You redirect customers to their authorization flow or embed their widget, and they return a token you use for future debits. The processor maintains the authorization records and handles disputes.
Building custom authorization gives you complete control over the user experience but requires careful implementation. You need to build forms that collect all required fields, implement IP address and timestamp capture, integrate an account verification method, build secure storage for authorization records, and create a system to retrieve records for disputes. If you choose this path, have a payments attorney review your implementation before launch.
Most teams building fintech products that aren't payment companies themselves are better served by processor-hosted solutions. The time and legal risk involved in custom implementation rarely justify the benefits unless authorization is a core differentiator of your product.
What Happens When Authorization Requirements Aren't Met
Failing to obtain or retain proper authorization has concrete consequences. If a customer disputes a transaction and you cannot produce valid authorization, you must return the funds. If this happens repeatedly, your payment processor or sponsoring bank may increase your reserve requirements, meaning they hold a percentage of your processed volume as insurance against returns.
NACHA tracks return rates by originator. If your unauthorized return rate exceeds thresholds (currently 0.5% for administrative returns including unauthorized debits), you may face fines or corrective action plans. Severe or repeated violations can result in removal from the ACH network entirely, which means you can no longer process ACH payments.
Beyond NACHA penalties, you may face enforcement action from the CFPB or state financial regulators if your authorization practices are deemed deceptive or unfair. Several fintech companies have faced consent orders and fines for processing payments without valid authorization or making it unreasonably difficult for customers to revoke authorization.
Getting ACH Authorization Right From the Start
ACH authorization requirements exist to protect consumers from unauthorized debits, and they're not negotiable. If your fintech app will process ACH payments, build compliant authorization from day one.
Start with clear, explicit authorization language that leaves no ambiguity about what the customer is agreeing to. Collect all required information fields including bank details, payment terms, and proof elements like IP and timestamp. Verify accounts before processing debits. Store authorization records securely for the required retention period.
If you're not sure whether your implementation meets requirements, have it reviewed by a payments attorney before processing live transactions. The cost of that review is trivial compared to the cost of returns, disputes, and potential removal from the ACH network.
Building fintech products that handle payments means getting compliance right, not just building features fast. Stardelite works with fintech clients to design and build compliant payment flows that meet regulatory requirements without sacrificing user experience. If you're building a product that needs ACH or other payment functionality, get in touch to discuss how we can help.
References
Share this:
6 min read