Nested Third-Party Senders: The ACH Role You Might Hold Without Knowing

There is a compliance position a lot of platforms hold without having chosen it: originating ACH on behalf of other businesses, through a partner rather than through a bank, and assuming the partner's compliance covers both of you.

Nacha has a name for that arrangement and a rule about it, and the rule says the assumption is wrong.

The definition turns on one thing

A "Nested Third-Party Sender" will be defined as 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.

Two conditions, and neither is about size, volume or self-description:

1. you have an agreement with another Third-Party Sender to act on behalf of an Originator
2. you do not have a direct agreement with the ODFI

If you originate ACH for other businesses and your contract is with a payments partner rather than with the bank carrying the traffic, you are probably looking at the shape of it. But check the first condition properly: the party you contracted with has to be a Third-Party Sender itself. A technology vendor that never originates ACH on anyone's behalf is not a TPS, so contracting with one does not make you nested — the absence of a direct ODFI agreement is necessary but not sufficient.

Software platforms, marketplaces and embedded-finance providers reach the position routinely — by integrating with a partner that is a TPS, which is the sensible commercial choice, and inheriting a role in the Rules as a side effect.

This is not a new rule. It took effect on 30 September 2022, with a six-month grace period for certain aspects. It appears here because the obligations are current and widely unrecognised, not because a deadline is approaching.

The chain of agreements

The rule builds a contractual chain rather than a registry of participants.

The ODFI's origination agreement with its TPS must address whether that TPS may have Nested Third-Party Senders — and if so, "push down" the requirement that an origination agreement exists between the TPS and the Nested TPS. An origination agreement then exists between the TPS and the Nested TPS.

Those changes to ACH origination agreements apply on a going-forward basis from the effective date, to agreements entered into on or after it. Nacha's own note is that ODFIs will notify TPSs of new rules even where they are not required to re-paper existing agreements.

On how deep the chain can go, the rule is silent by design:

[The Rules do not] address or limit the number of levels in a Nested Third-Party Sender arrangement.

What Nacha offers instead is an expectation: ODFIs "should understand that risk may increase with additional levels of removal from the Originator."

One obligation explicitly does not dilute with distance. The ODFI remains responsible for providing required information to RDFIs — proof of authorisation, for example — regardless of the number of Third-Party Senders involved in the transaction. Four parties removed from the originator, the bank still has to produce the authorisation. Which means somebody in your chain has to be able to hand it over, and if the chain has never been tested, nobody knows who.

The obligation you cannot outsource

This is the part that changes what a nested platform actually has to do.

The rule makes explicit that a Third-Party Sender, whether or not it is nested, must conduct a risk assessment, and must implement or have implemented a risk-management programme based on it. Then:

The obligation to perform a Risk Assessment, as well as the required Rules Compliance audit, cannot be passed onto another party; i.e., each participant will conduct or have conducted its own.

And, directly on the point:

Third-Party Senders that have relied on other TPSs' Risk Assessments or Rules Compliance Audits would need to conduct their own

If your current compliance posture is that your sponsor or your platform has this covered, that specific arrangement is what the rule was written to end.

One clarification worth carrying so you do not go looking for something that no longer exists: Nacha notes that Rules Compliance Audit requirements were removed from the Rules (Appendix 8). The audit is referenced in the non-delegation language above, but the standalone audit requirement is not something to search the current Rules for.

What the assessment has to contain — and why Nacha will not tell you

Nacha declines to prescribe a methodology, and its reasoning is worth reading rather than skipping:

Attempting to prescribe the exact topics and methods for a TPS risk assessment will likely over-prescribe risk and controls for some TPSs, and fail to identify risk and controls for others.

Each TPS "operates in a different space, with challenges, risks, and controls that will be different than the challenges, risk and controls faced by another TPS." So risk assessments "should not be one-size-fits-all."

What it does give you is a starting frame. Broad risk categories: operational, return, credit, fraud, compliance and reputational risk.

And a pointer to the ODFI risk-management requirements in Articles One and Two of the Rules, with worked examples including:

• performing customer due diligence
• setting and enforcing customer exposure limits
• auditing and testing originator authorisation processes and quality
• monitoring forward and return transaction volumes, dollars and rates
• establishing data-security policies, procedures and systems with access controls, authentication, authorisation and encryption
• SEC-code-specific risk-management requirements and warranties

Nacha also directs TPSs to guidance from banking regulators such as the OCC and the FDIC on risk-management expectations for ODFIs — which is a useful signal about the standard being applied. You are being measured against bank-style expectations, scaled to your activity.

A practical reading of "not prescribed": the absence of a checklist is not permission to produce something thin. It means nobody will tell you in advance which omission was the one that mattered.

Registration, and who does it

Registration is the ODFI's action, not yours — which has the same consequence it has under card scheme agent rules: your compliance status depends on a filing you cannot make.

The ODFI must identify in Nacha's Risk Management Portal all Third-Party Senders that allow Nested Third-Party Sender relationships. The timing follows the existing TPS registration timeframes:

And on request, the ODFI must provide Nacha with the nested relationships for any TPS.

Note the shape of the initial deadline. It is the later of the two, and the second limb runs from the ODFI becoming aware — so an ODFI that learns late about a nesting arrangement is not automatically in breach, but an ODFI that is never told cannot register at all. If you are nested and your partner has not told the bank, the clock has not started and the record is wrong.

What the ODFI is not doing

ODFIs would not be required to review TPS Risk Assessments, but may choose to institute policies to encourage TPS compliance

This is the sentence to internalise if you are relying on silence as approval. Nobody is marking your risk assessment. The bank's duty runs to registration and to its own due diligence on whether its TPS customers have nested relationships at all. Nacha lists among the rule's effects: "Reasonably expands ODFIs' due diligence to know whether TPS customers have Nested Third-Party Sender relationships".

So the failure mode is quiet. A thin or absent assessment produces no rejection, no warning and no signal, right up until something goes wrong and somebody asks to see it.

What an operator actually does differently

• Establish which role you hold, in writing. Ask your payments partner two questions: are we a Third-Party Sender, and do you have a direct origination agreement with the ODFI or are we nested behind you? The answer determines whether you have your own obligations.
• Ask whether the ODFI knows you exist. Registration timing runs partly from the ODFI becoming aware of the nesting. If your partner has not disclosed the arrangement, the Portal record is incomplete and you are invisible in it.
• Do your own risk assessment, even if one exists upstream. It cannot be inherited, and the rule names reliance on another TPS's assessment as the thing that must stop.
• Cover the six categories at minimum — operational, return, credit, fraud, compliance, reputational — and use the Articles One and Two examples as the control list rather than inventing one.
• Test who can produce a proof of authorisation. The ODFI owes it to the RDFI regardless of chain depth. Run the request through your chain once before a dispute forces it.
• Do not search for a Rules Compliance Audit requirement. It was removed from the Rules; the non-delegation principle survives it.
• Re-check your origination agreement if it predates 30 September 2022. The agreement changes applied going forward, so an older contract may simply be silent on nesting.

The honest summary

The nested Third-Party Sender rule is four years old and does not have a deadline attached, which is probably why it is under-read. Its substance is a single reallocation: it moves the risk-assessment obligation from somebody in the chain to each party in the chain, separately, with no borrowing.

For a platform that reached the TPS role by integrating with a partner rather than a bank, that is the difference between a compliance position you assumed you had and one you can actually evidence. For related scheme-side registration duties on the card networks, which pose the same question in a different vocabulary, see Visa Third Party Agent registration. For the current ACH fraud-monitoring obligations that sit alongside these, see Nacha's credit-push fraud rules.