Most merchant-services businesses that touch ACH do so through a bank. The platform collects the merchant's authorization and builds the file, and the sponsor bank transmits it into the network under its own routing number. From the platform's side that looks like a service the bank provides. From the rulebook's side it is the reverse: the platform is a Third-Party Sender, and a good part of the bank's own obligations under the Nacha Operating Rules attach to it directly.
An earlier piece on this site, on the 2026 fraud monitoring rules, used the label in passing without setting out what it means. This one does, drawing on Nacha's public rule pages and FAQs and on the rule text Nacha circulated for comment in May 2021 and adopted with effect from 30 September 2022, as of September 2026. The full current Rules are a Nacha product; where a detail rests on that proposed text rather than Nacha's published summary, we say so.
Who Is a Third-Party Sender, and Who Only Thinks They Are Not
Nacha defines a Third-Party Sender as a type of Third-Party Service Provider that acts as an intermediary on behalf of an Originator, or of another Third-Party Sender, in transmitting entries between the Originator and the ODFI, where the Originator and the ODFI have no direct relationship and origination agreement of their own. It must have an origination agreement with an ODFI, or with another Third-Party Sender acting on the ODFI's behalf, and it is never the Originator of entries it transmits for someone else, though it can originate other entries in its own right, such as its own payroll.
The test is not who builds the file or whose account the money passes through. It is who has the underlying obligation. Nacha's Third-Party Sender Identification Tool asks whether the customer is the party ultimately responsible for paying the Receiver on a credit, or ultimately benefiting from the funds debited on a debit. If the answer is a downstream client, the customer is a Third-Party Sender; in the tool's own words, even though funds settle into my account, they are for the benefit of my client. The mirror case is a merchant that holds its own origination agreement with the bank and outsources file creation to a software vendor: the vendor is then a service provider only, and none of what follows lands on it.
The Agreement Chain
An ODFI may originate entries initiated by a Third-Party Sender only under an origination agreement, and the Rules prescribe its contents. In the rule text, the Third-Party Sender must authorize the ODFI, on the Originator's behalf, to originate entries to Receivers' accounts; agree to be bound by the Rules and not to originate entries that violate US law; accept any restrictions on entry types; give the ODFI the right to terminate or suspend the agreement, or any of its Originators or Nested Third-Party Senders, for breach, and the right to audit their compliance; and agree that before any Originator originates through it, it will sign that Originator to an agreement meeting the same requirements the Rules set for an ODFI's own agreement with an Originator.
That last clause turns a sponsor-bank contract into an onboarding requirement: the merchant agreement your sales team sends out has to carry the Originator terms the Rules would require if the bank had signed the merchant itself, and it has to be in place before the first entry. The Rules add that a Third-Party Sender warrants to the ODFI that each Originator has agreed to assume an Originator's responsibilities, and indemnifies the ODFI for losses caused by an Originator's failure to perform them, or by its own.
Nested Third-Party Senders: The 2022 Rule
An ISO that originates through a payment facilitator's bank relationship rather than its own is one level further down the chain. Nacha's Third-Party Sender Roles and Responsibilities rule, effective 30 September 2022, named that position: a Nested Third-Party Sender is a Third-Party Sender that has an origination agreement with another Third-Party Sender to act on behalf of an Originator, and has no direct agreement with the ODFI. Unless the Rules say otherwise, every reference to a Third-Party Sender includes a nested one.
The rule works through the contracts. The ODFI's agreement with its Third-Party Sender must say whether nested relationships are allowed and, if they are, push the origination-agreement requirement down a level, so that an agreement with the prescribed terms exists at every link in the chain; Nacha's rule page is explicit that the rule neither addresses nor limits the number of levels. The changes applied to agreements entered into from the effective date, with ODFIs notifying existing Third-Party Senders rather than re-papering existing contracts.
Liability runs the whole length of the chain. An ODFI is responsible for each Nested Third-Party Sender as if it had a direct agreement with it, a Third-Party Sender is responsible for each Nested Third-Party Sender below it on the same basis, and a Third-Party Sender is jointly and severally liable with each of its Nested Third-Party Senders for the performance of their obligations. Nacha's impact note adds that the ODFI remains responsible for producing proof of authorization to a receiving bank however many Third-Party Senders sit between it and the merchant, so the request comes down the chain to whoever holds the record.
Registration: What the Bank Files About You, and What You Owe It
Since the Third-Party Sender Registration rule, effective 29 September 2017, every ODFI must either register each Third-Party Sender it originates for in Nacha's Risk Management Portal or state that it has none; there are no exemptions by volume or risk profile. The registration is basic: the Third-Party Sender's name and principal city and state, the routing numbers the ODFI uses in its entries, its Company Identification numbers and, since 2022, whether it originates for Nested Third-Party Senders. The ODFI must register within the later of 30 days of transmitting the first entry or 10 days of realising an existing customer is a Third-Party Sender, and must update the record within 45 days of any change, termination included.
The Third-Party Sender's side is in the same rule. It must disclose to the ODFI any other Third-Party Sender for which it transmits entries before it transmits them, and on request must supply whatever the ODFI needs to register it within two banking days. If Nacha believes a Third-Party Sender poses an escalated risk of financial loss, of a violation of the Rules or the law, or of excessive returns, it may ask the ODFI in writing for supplemental information, due within 10 banking days: doing-business-as names, taxpayer identification numbers, street and website addresses, a contact person, the principals' names and titles, the approximate number of Originators, whether it transmits debits, credits or both, and the names of its Nested Third-Party Senders. That is the file your ODFI expects you to be able to hand over inside two weeks.
The ODFI Obligations You Inherit
The heart of the Third-Party Sender rules is one clause: to the extent a Third-Party Sender performs any of the obligations of an ODFI, it must perform them as the Rules require of the ODFI, and warrants that it is legally able to do so. The rule text lists what that includes without limiting it: a risk assessment of its ACH activities; monitoring the origination and return activity of its Originators across multiple settlement dates; enforcing restrictions on the types of entries they may originate; and enforcing, for its Originators and Nested Third-Party Senders, the exposure limit set by the Third-Party Sender or the ODFI. Performing those duties relieves neither the ODFI nor any other Third-Party Sender in the chain of its own. The ODFI rule they come from also requires due diligence sufficient to form a reasonable belief that the customer can perform under the Rules, and an exposure limit that is set, implemented and periodically reviewed, per Originator.
Return rates are where monitoring becomes measurable. Under Nacha's ACH Network Risk and Enforcement Topics rule, effective 18 September 2015, an Originator or Third-Party Sender whose unauthorized debit returns, reason codes R05, R07, R10, R29 and R51, exceed 0.5 percent has breached a threshold, and its ODFI faces the Rules' obligations and potential enforcement for it. Two further figures are inquiry levels rather than violations: administrative returns, codes R02, R03 and R04, above 3 percent, and all debit returns other than RCK above 15 percent, either of which lets Nacha open a review of the Originator's or Third-Party Sender's practices. Nacha publishes the calculation method for each, and a Third-Party Sender that cannot produce those three numbers per Originator on demand is not monitoring in the sense the rule means.
Money and records follow the same pattern. A Third-Party Sender agrees to pay the ODFI for the credit entries it originates and for any debit entries the receiving bank returns; the Originator is liable only to the extent the ODFI is not paid by the Third-Party Sender. And a Third-Party Sender is jointly and severally liable with each of its direct or indirect Originators for retaining and delivering the records of authorization, copies of items and eligible source documents the Rules require. A merchant's failure to keep proof of authorization is the platform's problem.
Two Things Nobody Can Do for You
The 2022 rule made explicit what Nacha says was already implied: a Third-Party Sender, nested or not, must conduct or have conducted an assessment of the risks of its ACH activities, implement a risk management program on the basis of it, and comply with its regulators' requirements for both. It cannot rely on a risk assessment, or a rules compliance audit, completed by another Third-Party Sender in the chain. Nacha deliberately prescribed no methodology, on the reasoning that each Third-Party Sender operates in a different space with different risks and controls, but its rule page names the categories to expect: operational, return, credit, fraud, compliance and reputational risk, together with the ODFI duties in Articles One and Two, from customer due diligence and exposure limits to authorization quality, return monitoring and data security. The grace period for first-time assessments ran to 31 March 2023.
The audit is older and firmer. A Third-Party Sender must annually conduct, or have conducted, an audit of its compliance with the Rules, completed no later than 31 December each year under the direction of its audit committee, audit manager, senior officer or an independent examiner, covering its performance of any ODFI obligation. Nacha's Risk Management Portal page says that on request a financial institution must attest to completion of its own audit or a specified Third-Party Sender's, and that Nacha sends attestation requests each quarter to randomly selected institutions. A bank asked to attest to your audit will want to have seen it.
What Enforcement Looks Like From Where You Sit
Nacha's enforcement runs through the bank. Its FAQ on the registration rule says risk investigations and rules-enforcement communications always begin with the ODFI, which has the opportunity to respond, and that there are no automatic fines. Failure by an ODFI to register its Third-Party Senders was added to the list of Class 2 rules violations by the 2017 rule. Since 30 June 2021 the Rules also define an egregious violation, a willful or reckless action involving at least 500 entries or entries aggregating at least USD 500,000; a Class 3 sanction can reach USD 500,000 per occurrence together with a directive to the ODFI to suspend the Originator or Third-Party Sender, and Nacha may report Class 3 violations to the ACH Operators and to industry regulators.
What reaches a Third-Party Sender, then, is the bank's response to that pressure: a demand for the supplemental registration file, a request for the audit, a reduced exposure limit, or termination. Nacha's Terminated Originator Database, in the same portal, lets ODFIs and third parties record Originators and Third-Party Senders terminated for cause and check new ones against it before boarding; inclusion does not bar a relationship with another bank, but Nacha encourages banks to look. And Nacha Certified, its voluntary accreditation for Third-Party Senders with at least two years in business, asks for background checks on principals and key officers, two years of audited financial statements and the most recent Rules audit; Nacha says the criteria are worth meeting whether or not a Third-Party Sender applies, which makes them a fair list of what a sponsor bank is entitled to ask for.
What to Put in Place
- Settle the label first. If your merchants have no agreement of their own with the bank and the money moves for their benefit, you are a Third-Party Sender whatever the sponsor-bank contract calls you; any partner that originates through you is a Nested Third-Party Sender and needs an agreement with the prescribed terms before its first entry.
- Make the merchant agreement carry the Originator terms the Rules require, and keep the signed copy with the authorization records. You are jointly and severally liable with the merchant for producing them.
- Keep the registration file current: legal and DBA names, tax IDs, addresses, principals, Originator count, debit or credit, and the names of any Nested Third-Party Senders. Disclose a new nested relationship before the first entry, and answer a registration request within two banking days.
- Compute the unauthorized, administrative and overall return rates for every Originator the way Nacha's method prescribes, and record the exposure limit you set and how you enforce it.
- Do your own risk assessment and your own Rules audit, the audit by 31 December each year, and send the audit to the sponsor bank without being asked. Neither can be inherited from the payment facilitator above you or delegated to the ISO below you.
Tags
About the author
Kyle Hall
Founder
Kyle Hall is a fintech entrepreneur, software engineer, and marketing strategist with over a decade of experience in high-risk payment processing and SaaS development. He is the CEO of PayKings, a leader in high-risk merchant services, and the founder of PulseCRM, a purpose-built CRM platform for the payments industry. Kyle specializes in building custom payment processing systems and growth strategies that empower merchant services providers to scale and succeed in the digital marketplace.