An ACH Third Party Sender is an intermediary that transmits ACH payment entries to a bank on behalf of other businesses, holding its own agreement with that bank rather than putting each business into a direct banking relationship. If you operate as one, your obligations run through Nacha’s Operating Rules: your bank has to register you, you need specific written agreements in place, and you owe an annual compliance audit, an annual risk assessment, ongoing return-rate monitoring, and (beginning in 2026) documented fraud detection. Getting any of it wrong can lead to fines reaching six figures per month or suspension from the network.
What a Third Party Sender Does
A Third Party Sender (TPS) sits between the business that wants to send or collect a payment, called the Originator, and the bank that connects to the ACH network, called the Originating Depository Financial Institution or ODFI. The defining feature is contractual: the TPS holds the agreement with the ODFI. The Originator does not. The ODFI relies on the TPS to vet and manage every Originator it brings to the network.1Nacha. Third-Party Sender Roles and Responsibilities
This role is not the same as a Third-Party Service Provider, which might build payment software or handle data processing but doesn’t hold its own ODFI agreement and doesn’t transmit entries on an Originator’s behalf. The distinction matters because a TPS sits in the direct line of liability for every transaction it processes. If an Originator sends unauthorized debits or generates excessive returns, the TPS answers to the ODFI and, ultimately, to Nacha.
Day to day, a TPS typically formats payment files, submits entries to the ODFI, manages return items, and ensures each Originator complies with the specific Standard Entry Class codes permitted under its agreement (PPD for payroll, CCD for business-to-business payments, and so on).2EPCOR. Third-Party Sender Because the TPS is the ODFI’s single point of contact for potentially dozens or hundreds of underlying businesses, the compliance burden is real.
Registration Through Your ODFI
A common misconception is that the TPS registers itself with Nacha. It doesn’t. The ODFI registers each of its Third Party Sender customers in Nacha’s Risk Management Portal.3Nacha. Third-Party Sender Registration The timelines are tight:
- For a new TPS relationship, the ODFI must register the TPS within 30 days of transmitting the first ACH entry on the TPS’s behalf.
- If an ODFI realizes an existing customer is actually functioning as a TPS, it has 10 days to complete the registration.
- Any change to previously submitted information must be reflected in the portal within 45 days.
Nacha charges no fee for registration. The cost is covered through Network Administration Fees already built into the industry’s broader fee structure.3Nacha. Third-Party Sender Registration
What Information Gets Registered
The initial registration collects data your ODFI should already have from onboarding: the ODFI’s name and contact information, the TPS’s legal name and principal business location, the routing number used in ACH transactions originated for the TPS, and the Company Identification numbers the TPS uses in its entries.3Nacha. Third-Party Sender Registration
Nacha can request supplemental information in writing, and the ODFI has 10 banking days to respond. That supplemental request can cover doing-business-as names, taxpayer identification numbers, street address, and website; the primary contact person; the names and titles of principal owners or officers; and a volume profile describing the approximate number of Originators served and whether the TPS transmits debits, credits, or both.
Your practical job is to make sure your ODFI has all of this before the first transaction hits the network, and to notify the bank promptly whenever something changes. Delays on your end translate into the ODFI missing its deadlines, which creates enforcement exposure for both of you.
Agreements You Need in Place
The ODFI-TPS Agreement
The contract between the TPS and its ODFI is the foundation of the relationship. It must bind both parties to the Nacha Operating Rules and specify which Standard Entry Class codes the TPS is authorized to originate.4Nacha. How ACH Works It should address whether the TPS can maintain nested TPS relationships and, if so, require the TPS to execute origination agreements with each nested entity.
Indemnification is a major component. ODFIs expect the TPS to cover losses arising from unauthorized or erroneous entries, Originator failures, reversals, and any noncompliance with Nacha Rules or applicable law. In practice, the TPS absorbs the financial hit when an Originator misbehaves. Agreements also typically include exposure limits, the right to suspend processing immediately for noncompliance, and audit rights allowing the ODFI to inspect the TPS’s operations.
The TPS-Originator Agreement
The TPS must maintain a written agreement with each Originator it serves. That contract needs explicit authorization from the Originator to initiate entries on its behalf and a clear statement that the Originator agrees to be bound by the Nacha Operating Rules.4Nacha. How ACH Works Beyond that baseline, a well-drafted agreement covers the specific entry types permitted, transaction volume limits, procedures for handling returns, and a termination clause allowing the TPS to cut off access if the Originator violates the rules or exceeds exposure limits.
For consumer transactions, Regulation E adds obligations around disclosures and error resolution.5eCFR. Electronic Fund Transfers (Regulation E) The primary obligations sit with the ODFI and Originator, but a TPS that fails to ensure its Originators are meeting those obligations creates risk that rolls uphill to the ODFI.
Nested Third Party Senders
A nested TPS is a Third Party Sender that doesn’t have its own direct agreement with an ODFI and instead works through another TPS that does. Nacha formalized rules around these arrangements effective September 30, 2022, because layering creates additional risk that someone in the chain could be originating questionable transactions without adequate oversight.1Nacha. Third-Party Sender Roles and Responsibilities
The primary TPS must disclose the identity of any nested TPS to the ODFI before transmitting entries on the nested entity’s behalf. The ODFI must then flag in the Risk Management Portal that this TPS allows nesting. The origination agreement between the ODFI and the primary TPS must specifically address whether nesting is allowed, and if it is, require a separate origination agreement between the primary TPS and each nested TPS. Registration timelines match the standard rule: 30 days from the first transmitted entry, or 10 days from the ODFI becoming aware.
Every nested TPS must independently conduct its own compliance audit and risk assessment. You cannot rely on the primary TPS’s audit to cover you.
Annual Compliance Obligations
Rules Compliance Audit
Every TPS must complete a Rules Compliance Audit by December 31 of each year. The audit evaluates internal operations against the current Nacha Operating Rules, examining authorization procedures, data handling, transaction accuracy, and return management. Documentation must be retained for at least six years.6Nacha. ACH Operations Bulletin 3-2025 – Automating Request for Proof of Audit ODFIs can request proof of the audit at any time, and Nacha has automated the request process to make spot-checks easier.
Annual Risk Assessment
Separately from the audit, each TPS must perform an annual risk assessment addressing threats to payment system integrity and the security of sensitive data. The assessment should address physical and electronic safeguards, access controls, authentication methods, encryption practices, and SEC code-specific risks.1Nacha. Third-Party Sender Roles and Responsibilities ODFIs are not required to review TPS risk assessments, but many do as part of their own risk management, and if your ODFI asks for a copy, you need to produce one.
Each TPS must conduct its own audit and risk assessment independently. A nested TPS cannot rely on the primary TPS’s compliance work, and a TPS cannot delegate these obligations to a service provider and call it done.
Data Security
Nacha requires ACH account numbers to be rendered unreadable when stored electronically. The obligation currently applies to any TPS, merchant, or other entity that processes 2 million or more ACH transactions annually. Encryption, tokenization, and truncation all satisfy the requirement, and the standard aligns with existing PCI DSS expectations. Your annual risk assessment should document these safeguards and identify any gaps.
Return Rate Thresholds
Nacha monitors return rates at three levels, applied per Originator or per TPS:7Nacha. ACH Network Risk and Enforcement Topics
- Unauthorized return rate: 0.5% of debit entries.
- Administrative return rate: 3.0% of debit entries returned for account data errors (wrong account number, no such account, or invalid account number).
- Overall return rate: 15.0% of all debit entries returned for any reason.
Exceeding a threshold does not automatically constitute a violation or trigger a fine. It opens a preliminary inquiry into your origination activity to determine whether a reduction is warranted. The unauthorized return rate is where most enforcement trouble begins. The ODFI must report when an Originator or TPS exceeds the 0.5% threshold and may require corrective action. If you can’t get your Originators under control, the ODFI faces its own regulatory pressure and may terminate the relationship.
A TPS should monitor return rates continuously rather than wait for Nacha to flag a problem. High administrative returns usually point to bad account data from Originators, which is fixable with better validation at intake. High unauthorized returns suggest Originators are debiting consumers without proper authorization, which is a much more serious problem.
BSA, AML, OFAC, and FinCEN
Nacha compliance alone doesn’t cover the full regulatory picture. Federal anti-money laundering rules under the Bank Secrecy Act impose additional obligations that flow through the ODFI-TPS relationship. Banks that provide accounts to third-party payment processors must develop risk-based policies to authenticate the processor’s business operations and assess their risk level. Expect your ODFI to run background checks on your business and its principal owners, review your due diligence standards for onboarding merchants, ask you to identify major customers by name and transaction volume, and periodically audit the relationship.8FFIEC BSA/AML InfoBase. Risks Associated with Money Laundering and Terrorist Financing – Third-Party Payment Processors
OFAC sanctions screening adds another layer. The ODFI is responsible for verifying that Originators are not blocked parties, and for domestic ACH transactions, the ODFI and the receiving bank generally rely on each other to screen their respective sides. The bank remains ultimately responsible even when a third party performs the screening.9FFIEC BSA/AML InfoBase. Office of Foreign Assets Control For international ACH transactions, the ODFI cannot rely on a foreign receiving bank’s screening and must exercise heightened diligence.
Whether a TPS itself qualifies as a “money transmitter” under FinCEN regulations depends on the payment processor exemption. To qualify, the TPS must facilitate the purchase of goods or services (not money transmission itself), operate through clearing and settlement systems that admit only BSA-regulated financial institutions, operate under a formal agreement, and hold that agreement with at least the seller or creditor receiving the funds.10FinCEN. Application of Money Services Business Regulations to a Company Acting as an Independent Sales Organization and Payment Processor Most ACH TPS operations meet these conditions. If your business model involves disbursing funds outside the regulated banking system, you may need a state money transmitter license.
Enforcement and Fines
Nacha’s enforcement structure escalates through three classes. A Class 1 violation, the least severe tier, applies when a problem goes unresolved for a year or recurs. Fines start at up to $1,000 for the first occurrence and can reach $5,000 by the third recurrence. Unresolved Class 1 issues escalate to Class 2, where Nacha’s Rules Enforcement Panel can levy fines up to $100,000 per month until the problem is fixed. Class 3 kicks in after three consecutive months of unresolved Class 2 violations, raising the ceiling to $500,000 per month. At the extreme end, Nacha can suspend the entity’s ability to originate entries entirely.
These fines can hit the ODFI, the TPS, or both. In practice, ODFIs pass the financial exposure down to the TPS through indemnification provisions. A TPS that ignores a compliance deficiency isn’t just risking a Nacha fine; it’s risking the loss of its banking relationship, which effectively shuts down the business.
Failing to complete the annual audit or risk assessment, letting registration information go stale, or allowing Originators to chronically exceed return rate thresholds are all common paths to enforcement. The pattern that gets entities into the most trouble is treating the first warning as background noise. By the time Class 2 fines are on the table, the cost of remediation is a fraction of the monthly penalty.
2026 Fraud Monitoring Rules
New Nacha rules taking effect in 2026 add fraud detection requirements that directly affect Third Party Senders. The rollout happens in two phases.
On March 20, 2026, entities that originate 6 million or more ACH transactions annually must implement risk-based processes to identify entries initiated due to fraud, including unauthorized entries and entries authorized under false pretenses. This phase also requires standardized company entry descriptions: “PAYROLL” for employee wage payments and “PURCHASE” for consumer-authorized purchases.
On June 22, 2026, the same fraud monitoring requirements extend to all remaining non-consumer originators, third-party service providers, and Third Party Senders regardless of volume. After that date, every TPS in the network will need documented fraud detection procedures. TPS platforms also need to update file formatting to map the standardized entry descriptions automatically, since using the wrong description will itself become a compliance issue.