Nested third party sender examples: who waits on whom

Nested third party sender examples share one shape: a processor that originates ACH for its own clients, but sends the files through another third-party sender that holds the origination agreement with the bank. Nacha’s own example is a tuition processor that sends a university’s debits through a larger “direct processor”; in practice it is just as often a billing company riding on a payroll processor, or a reseller behind a merchant processor. The bank never signed anything with the nested sender, yet it registers it, warrants its entries and answers for the originators behind it. That is why the work is hard: everything the bank knows arrives through the first sender, unless the bank reads its own files. Botminds’ Third-Party Sender Due Diligence does that reading, comparing every Company Identification, name and addenda record in the bank’s ACH files with the roster the sender supplied, so a sender behind the sender is found by the bank rather than by an examiner.

The sample case on this page is fictional: Tessaly Community Bank, its sender Larkfield Payroll Services and Larkfield’s 1,240 originators, as they run through the solution. The rules come from Nacha’s public rule pages and the federal banking agencies, linked where they are used.

What is a nested third party sender? The definition Nacha wrote in 2022

A nested third-party sender is a sender with no agreement of its own with the bank. Nacha put the definition into its rules on September 30, 2022: a nested third-party sender is “a Third-Party Sender that has an agreement with another Third-Party Sender to act on behalf of an Originator, and does not have a direct agreement with the ODFI” (Nacha, Third-Party Sender Roles and Responsibilities). Everything else follows from that missing contract.

The 2022 rule did four things with the definition. It made the origination agreement between the bank and its sender say whether nested senders are allowed, and “push down” the requirement for an origination agreement between the sender and any nested sender. It set out a chain of agreements, so obligations and warranties run link by link. It added a flag to registration in Nacha’s Risk Management Portal for every sender that allows nested relationships. And it made explicit that every sender, nested or not, does its own risk assessment and its own Rules Compliance Audit, a point the third party sender requirements guide works through one by one.

The industry asked for it. When Nacha consulted on the change, 69 organisations replied, 43 of them financial institutions, and the agreement was close to unanimous on the basics.

Nested third party sender examples from Nacha, the FDIC and the FFIEC

The clearest examples come from the rule-maker and the regulators themselves, and they have a common thread: one intermediary handing its traffic to another that already has a bank. Four patterns recur.

The processor behind a direct processor. In Nacha’s tuition scenario, a tuition processor collects students’ debits for a university but has no agreement with the bank; it has one with a direct processor that does. Nacha’s conclusion is that “both the Tuition Processor and the Direct Processor are Third-Party Senders under the Rules, as they both are intermediaries between the ODFI and the Originator” (ACH Operations Bulletin #2-2014). The university remains the originator, because the students owe the tuition to it.

The merchant that is also a processor. The FDIC’s payment processor guidance names this one directly: it can be hard to get information from a processor “particularly if a merchant is also a payment processor, resulting in a ‘nested’ payment processor or ‘aggregator’ relationship” (FDIC FIL-3-2012, as revised February 2026). On a roster, such a business looks like any other originator.

The reseller. The FFIEC’s BSA/AML examination manual asks banks to determine whether a processor re-sells its services to a third party “who may be referred to as an ‘agent or provider of Independent Sales Organization (ISO) opportunities’ or ‘gateway’ arrangements” (FFIEC BSA/AML Manual, Third-Party Payment Processors). Whoever buys that access and originates for its own clients is, in Nacha’s terms, a nested sender.

The billing company riding on a payroll processor. This is the sample case. Larkfield Payroll Services sends payroll, billing and membership debits for 1,240 companies. Inside its files sits Company Identification 9004218833, QuickRun Billing, which sent web and telephone debits through Larkfield for 230 days, 56,400 entries worth $27.9 million, and whose own business is processing recurring payments and invoices for small service businesses. Larkfield’s registration says it has no nested senders. Its files say otherwise.

How many levels can a nested third party sender have?

As many as the parties build: Nacha sets no limit. The rule page says it plainly: “This rule amendment does not address or limit the number of levels in a Nested Third-Party Sender arrangement” (Nacha). A bank that allows nesting in its agreement has, in principle, allowed a chain of any depth below it.

Nacha also says what depth does to risk. In the impact section of the same rule: “ODFIs should understand that risk may increase with additional levels of removal from the Originator.” The FDIC goes further. Nested processors and aggregators “may be extremely difficult to monitor and control; therefore, risk to the institution is significantly elevated in these cases” (FDIC FIL-3-2012), and the bank “should be aware of these activities and obtain data on the nested processor and its merchant clients.”

The practical consequence is that a policy should decide depth, not leave it to the agreement’s silence. A bank can allow one level with its prior written consent and none below it, or allow none at all; either is a policy a committee can defend. What is not defensible is an agreement that allows nesting while the bank has no way to see a second level when one appears.

Who waits on whom in a nested chain

In a nested chain the bank waits on its sender for almost everything it needs, and the sender waits on the nested sender. The rules give the bank some leverage: a sender must disclose any other sender it transmits for “prior to transmitting entries for the other Third-Party Sender,” and must hand over registration information on request “within 2 banking days” (Nacha, Third-Party Sender Registration FAQ). But a duty to disclose is not the same as disclosure.

Inside the bank, the waiting has names. The analyst waits on a roster that arrives once a year in whatever shape the sender keeps it. The BSA officer waits on screening evidence for companies the bank has never met. The relationship owner waits on the sender for every missing document, and the committee waits on all three. In the sample bank those are four people, and the solution changes what each of them waits for.

Does the ODFI have an agreement with a nested third party sender?

No, and by definition it cannot: once the bank signs with it directly, it stops being nested and becomes the bank’s own sender. The OCC described the same gap a level up in 2006: “When a third-party sender is interposed between the bank and the originator, there is no contractual agreement between the bank and originator” (OCC Bulletin 2006-39). A nested sender adds a second missing contract.

So the bank’s levers all sit in its agreement with the first sender. The OCC lists what those agreements generally do: set risk parameters, detail the sender’s obligations, define what the bank must receive before a new originator is added, “Define approved and disallowed originator and transaction types,” “Provide the bank ongoing access to all originators’ files,” and keep the bank’s right to audit. A nesting clause belongs in the same list. Larkfield’s agreement, section 7.3 dated June 1, 2022, says the sender “shall not permit any Nested Third-Party Sender to transmit Entries through the ODFI without the ODFI’s prior written consent,” and must tell the bank within five banking days of any request. QuickRun Billing sent for 230 days; the consent was never asked for.

A clause like that is only as good as the bank’s ability to notice its breach. Nothing in the sender’s annual roster would have shown it, because a nested sender is not a row on its host’s roster of originators. It shows up in the files.

Who registers a nested third party sender, and by when?

The bank does. Nacha’s 2017 registration rule already applied “to Third-Party Senders that are the ODFI’s direct customers, as well as those other Third-Party Senders that are direct customers of the first Third-Party Sender, otherwise known as ‘nested’ Third-Party Senders” (Nacha). The 2022 rule added the flag and the clock: a sender with nested senders “will be registered as such within the later of 30 days of Transmitting the first Entry, or within 10 days of the ODFI becoming aware of the Nested TPS” (Nacha). Registration information must then be updated within 45 days of any change, and the portal is the same one that holds proof-of-audit requests and the Terminated Originator Database (Nacha Risk Management Portal).

The later-of construction matters for the reading of a late discovery. A bank that finds a nested sender in month eight has not automatically broken the 30-day clock; it has ten days from the day it knew. What it has lost is the eight months in which entries went out under its routing number from a party it had never assessed. The 230 days in the sample case do not, by themselves, make the bank’s registration late; they are 56,400 entries the bank warranted without having assessed the party that sent them.

How do you find a nested third party sender in your own files?

You compare what is sent with what is declared. A nested sender almost always leaves traces in the bank’s own ACH files that no roster shows, and four are worth testing every day rather than once a year.

A Company Identification or company name that sends but is not on the roster. In the sample, Company Identification 9004218833 sent under the name QUICKRUN BILLING in every batch; the 1,240-row roster supplied on October 6 had no row with that identifier or that name. Addenda that name other businesses. QuickRun’s addenda named 37 companies, its own clients. An originator whose own business is processing payments. QuickRun’s website describes recurring billing for small service businesses. An agreement that does not allow it. Section 7.3 required consent. Any one is a question; together they are a finding.

A sender behind the sender, with the five pieces of evidence that made it a suspect

The nested sender’s own rates can look fine. QuickRun’s unauthorized return rate was 0.38%, inside Nacha’s 0.5% threshold, which is why a return-rate alert would never have surfaced it. The risk is not a rate; it is 37 companies screened by nobody the bank can name. How a sender’s healthy average can hide originators over the line is the subject of third party sender ACH risk one layer down.

Click the finding, read the search itself

What the bank does once it finds a nested sender

Finding the nested sender starts five pieces of work, and the order matters. First, a decision on the entries: hold them for the committee or suspend them pending registration. The sample bank’s settings hold a suspected nested sender for the committee for two business days; the committee chair suspended QuickRun’s entries pending registration, with a reason code, in her own words. Second, registration, inside the ten-day clock. Third, the agreement: either amend it to permit and bind the nested sender, or end the arrangement. Fourth, the nested sender’s own risk assessment and Rules Compliance Audit, which Nacha says it must have and cannot borrow. Fifth, due diligence on the clients behind it, which is the work the FDIC means by obtaining “data on the nested processor and its merchant clients.”

In the sample, those became remediation items with owners, dates and the record that closes each: suspension confirmed by ACH operations on October 20, registration by October 30, the amended agreement by November 13, QuickRun’s own audit and assessment by December 31, and a plan for establishing which party holds the agreement and evidence for each of the 37 companies by November 20. None of them is closed by the person who raised it. Whether QuickRun was a nested sender at all, or an originator acting on its own behalf, is a judgement the bulletin’s test decides, and originator vs third party sender walks through it.

Anything that may become a suspicious activity report stays outside this work. In the sample, that matter sits with the BSA officer in the financial-crime case file and never appears in the review, the committee packet or the request to the sender. To see the whole review, from the roster to the signed decision, start from Third-Party Sender Due Diligence.

Questions people ask

What is an example of a nested third-party sender in ACH?

Nacha’s own example is a tuition processor that collects students’ debits for a university but sends them through a direct processor that holds the bank agreement; Nacha treats both processors as third-party senders and the university as the originator. A billing company that sends its clients’ debits through a payroll or merchant processor is the same shape.

Does a nested third-party sender need its own Rules Compliance Audit?

Yes. Since Nacha’s 2022 rule, a third-party sender cannot rely on a Rules Compliance Audit or a risk assessment completed by another sender in its chain; it must conduct or have its own. The audit is due by December 31 each year, like everyone else’s.

Can a bank prohibit nested third-party senders?

Yes. The 2022 rule requires the bank’s origination agreement with each sender to address whether nested senders are allowed, so a bank can refuse them outright or allow them only with its prior written consent. The prohibition is only as strong as the bank’s ability to see a breach in its own files.

What is the difference between a nested sender and an originator on the roster?

An originator has the underlying obligation with the receiver, such as a gym owed its membership dues. A nested sender transmits entries for other businesses that hold those obligations. A roster row can be either, which is why an originator whose own business is payment processing deserves a second look.

Where does a bank register nested third-party senders?

In Nacha’s Risk Management Portal, through the third-party sender registration it already uses. Banks identify every sender that permits nested relationships and must give Nacha the nested relationships for any sender on request.