The Nacha third party sender identification tool is a free, interactive question sequence on nacha.org that helps a bank, or a business, work out whether an ACH customer is an originator, a third-party sender or a service provider when an intermediary is involved. It asks who has the underlying obligation to the receiver and who holds the origination agreement with the bank, and ends with a classification and a next step. That is the right first question, and it is a single question about a single relationship. A bank with senders then has to register each one in Nacha’s Risk Management Portal, know every originator behind each, measure their returns, read each sender’s audit and decide, every year and in between. Botminds’ Third-Party Sender Due Diligence is built for that second part: every originator behind every sender screened, evidenced and measured from the bank’s own files, with the analyst, the BSA officer and the committee deciding.
The examples on this page come from a fictional sample program: Tessaly Community Bank, 34 senders and 18,600 originators, as they run through the solution. The tool’s questions are quoted from Nacha’s own page.
From the identification tool to a running program in Third-Party Sender Due Diligence
A person decides
ClassifyThe bank answers the tool’s questions for a customer, or applies the same test itself: who owes the receiver, and who holds the origination agreement.
A person decides
RegisterA portal administrator registers the sender with Nacha, flags any nested senders and updates the record within 45 days of a change.
Agent
Load and readAgents read the registration, the agreement and the sender’s roster in whatever shape it arrives, and screen every originator.
Never: Register, amend a registration or clear a screening hit.
Agent
Measure and compareAgents measure each originator’s returns from the bank’s files and compare what is sent with what is declared, every morning between reviews.
Never: Suspend or release entries, or conclude on a suspected nested sender.
A person decides
DecideThe analyst prepares, the BSA officer confirms screening, the committee approves, conditions or suspends with a reason code.
What Nacha’s third party sender identification tool does
It classifies roles. Nacha’s page says “The Third-Party Sender Identification Tool was developed to help financial institutions and their ACH customers understand their roles when an intermediary is involved in some aspect of ACH payment processing,” and explains why a tool rather than a list: “With the proliferation of new payment models, there is an undefinable amount of business case scenarios, so documenting them all and the roles associated with each is not possible” (Nacha, Third-Party Sender Identification Tool).
The reason a bank uses it is an obligation stated on the same page: “ODFIs in particular are required to know the nature of their customers’ use of the ACH Network, whether as Originators, Third-Party Senders, or other types of intermediaries.” The tool is also explicit about its limits. It “is not intended to provide legal advice,” and Nacha encourages banks to get their own counsel on their obligations. Nacha’s portal page sends banks to it for the same purpose: when unsure whether third-party customers are senders, “use the Third-Party Sender Identification Tool, or contact your local Payments Association, or Nacha” (Nacha Risk Management Portal).
How to identify a third party sender: the questions the tool asks
The tool starts by asking which kind of organization is using it, a bank or a business, and then works through the same two questions Nacha’s 2014 operations bulletin set out. For a bank looking at a customer, the first is whether the customer itself owes the receiver, or is owed by it, under an agreement or contract of its own. For a business, the agreement question comes in its own words: “Do I have an Origination Agreement directly with an ODFI to originate my ACH entries?”
The outcomes are short and practical. A customer with the obligation and its own agreement is an originator, which may outsource file work to a service provider without changing its role. A customer acting for a downstream party that owes the receiver is a sender. And where the answers are not known, the tool says so plainly: “I need to contact my ACH customer to determine whether it is an Originator or a Third-Party Sender and proceed as appropriate.” Nacha’s bulletin adds the step the tool assumes: analyse each kind of entry separately, because one business can be an originator for its own fee debits and a sender for its clients’ payments (ACH Operations Bulletin #2-2014). The worked cases are in third party sender vs third party service provider and originator vs third party sender.
Nacha register third party sender: the Risk Management Portal step
Once a customer is a sender, the bank registers it in Nacha’s Risk Management Portal, the same system that holds the ACH Contact Registry, proof-of-audit requests, direct access registration and the Terminated Originator Database. Registration is due within 30 days of the sender’s first entry, or within 10 days of the bank determining that an unregistered customer is a sender, and must be updated within 45 days of any change (Nacha, Third-Party Sender Registration). A bank with no senders still files, acknowledging that in a statement to Nacha.
Two portal details trip up programs. Since 2022 the bank must identify every sender that permits nested senders, on the later of the same two clocks after it becomes aware (Nacha). And the portal is run by named administrators, “Each financial institution may have up to six administrators,” who also receive Nacha’s quarterly proof-of-audit requests, so keeping that list current is part of the program, not an IT detail.
Is there a third party sender registration database you can search?
The registry is Nacha’s risk management tool rather than a public directory. Nacha’s FAQ describes what it does with the information: provide baseline information on senders in the network, and “Identify instances in which a Third-Party Sender uses multiple ODFIs” and instances in which a sender “is terminated by one ODFI but is registered by one or more other ODFIs,” and support risk investigations (Nacha).
The database a bank does search for due diligence is the Terminated Originator Database in the same portal. Nacha encourages banks to use it to investigate new originators and senders before onboarding and “To periodically verify your current Originators and Third-Party Senders, ensuring they haven’t been recently terminated by another ODFI” (Nacha Risk Management Portal). A listing is a reason for questions rather than a bar; the OCC has long warned that some senders use several banks because one relationship was terminated (OCC Bulletin 2006-39).
The identification tool, the portal and a program: what each does for the bank
| Need | Nacha’s identification tool | Nacha’s Risk Management Portal | The bank’s own program |
|---|---|---|---|
| Is this customer a sender? | Yes: a question sequence for one relationship | No | Applies the test to every customer, and re-applies it when the files change |
| Register the sender and its nested flag | No | Yes: registration, updates, nested flag | Knows when an update is due, from the files |
| Know every originator behind the sender | No | No | Roster read in full; every originator screened and evidenced |
| Check terminations elsewhere | No | Yes: Terminated Originator Database | Runs the check at onboarding and periodically |
| Measure returns per originator | No | No | From the bank’s own files, against the threshold and levels |
| The sender’s audit and risk assessment | No | Proof-of-audit attestations on request | Reads date, period and scope; follows up findings |
| Decide, and show the decision | No | No | Reason codes, signatures, an evidence pack for the examiner |
How long to implement third party sender monitoring?
The honest answer is that the length depends less on software than on how quickly the bank can put its own material in front of it. A pilot on one sender needs four things from the bank: that sender’s registration and agreement, its latest roster, a period of the bank’s own ACH origination and return files, and the bank’s settings for levels, cycles and approvers. The plan below is an illustration of the sequence, not a commitment: our estimate for one sender, assuming the material arrives in the first week.
An illustrative pilot on one sender, week by week
| Week | Who | What happens | Done when |
|---|---|---|---|
| 1 | The bank | Sends the sender’s registration, agreement and latest roster, and gives read-only access to a period of ACH origination and return files | Every document opens in the solution as received |
| 2 | The bank, then the agents | Sets levels, cycles, approvers and reason codes; the agents prepare a first review on every originator | A full review with findings, each citing its record |
| 3 to 4 | The bank and Botminds | Plant known problems in a copy of the sender’s data; count what the review finds; fix what it misses | The count is written down, misses included |
| 4 to 6 | Analyst, BSA officer, committee | Decide on the pilot review with reason codes; the daily watch runs on the sender’s files | A signed decision and a remediation plan with owners |
Weeks 3 and 4 are where a buyer should spend attention. A first review that comes back fast proves the software reads files; it does not prove the review finds what matters. The sample third party sender risk assessment describes the six-problem test that does, and a pilot without it is a demonstration rather than an evaluation.
What you bring to go live, and why each item matters
Everything the solution reads is something the bank already holds, or should. The list below is what the sample program runs on; each item is also a question an examiner may ask to see.
What a bank brings to run third-party sender due diligence on its own senders
- Registration records for each sender
So the Company Identifications actually sending can be compared with the ones registered.
- Origination agreements and amendments
So each clause on nesting, warranties, access and termination can be quoted back with its page.
- Each sender’s originator roster, in whatever shape it arrives
Spreadsheet, export or report; the roster is read as supplied rather than retyped.
- A period of the bank’s own origination and return files
Read-only, so each originator’s rates are computed from the bank’s data, not the sender’s.
- Screening and customer due diligence evidence
Where formation documents and ownership certifications are indexed, and how screening results are confirmed.
- Each sender’s latest Rules Compliance Audit and risk assessment
So scope, period and findings can be read, not just the date.
- The bank’s policy as settings
Review cycle by tier, the three return lines and window, the nested-sender rule, approvers, reason codes, second-signature threshold, retention.
The bank’s policy, as settings with a version history
What software do banks use for third party sender due diligence? What to ask
Banks use a mix: Nacha’s tool and portal for classification and registration, the payments platform’s reports for returns, a screening system, spreadsheets for rosters and a shared folder for the rest. The gaps sit between them, at the originator layer the guidance cares about. The FDIC’s guidance names the expectation software has to meet: the bank cannot rely solely on the processor, and the more it relies on the processor without its own verification, the more it needs an independent review (FDIC FIL-3-2012).
Seven questions separate tools that close those gaps from tools that move them. Does it read the roster as the sender sends it? Does it measure every originator from the bank’s own files? Does it compare the files with the roster, so an undeclared sender is found? Does it read an audit’s scope against the entry types actually sent? Does every value open the record it came from? Can it approve, suspend, register or clear a screening hit, and if it can, who answers for that? And can the bank set its own levels, cycles and approvers, with every change recorded?
A program view: 34 senders, each number opening its list
Where Third-Party Sender Due Diligence sits next to Nacha’s tool and portal
It fits after classification. It takes the senders the bank has identified, prepares each review on every originator, finds a sender behind a sender in the files, watches the files every morning between reviews and puts each finding in front of a named person with its record and a reason code. It keeps report-filing matters with the BSA officer and out of the review.
It does not replace Nacha’s tool or portal: the bank still classifies, and a registered administrator still registers and attests. It does not set the bank’s risk appetite or decide on its behalf. And it is not a substitute for testing: the right way to buy it, or anything like it, is to run it on one of your own senders with known problems planted, and count. To see the sample program, start from Third-Party Sender Due Diligence.
Questions people ask
Is the Nacha third party sender identification tool free?
Yes. It is a public page on nacha.org, open to banks and businesses, that walks through the questions for one relationship at a time. Nacha says it is not legal advice and encourages banks to get their own counsel.
Where do banks register third-party senders?
In Nacha’s Risk Management Portal, through third-party sender registration. Every originating bank either registers its senders or acknowledges that it has none, and updates the record within 45 days of any change.
How many administrators can a bank have in the Risk Management Portal?
Up to six, according to Nacha. Administrators receive Nacha’s quarterly proof-of-audit attestation requests, so the list should be kept current.
Can a business use the tool to check its own role?
Yes. The tool has a separate path for businesses, asking whether they have an origination agreement directly with a bank and whether they send files for clients. Its outcomes include a sender without the proper agreements, which should contact its bank.
Does registering a sender complete the bank’s due diligence?
No. Registration gives Nacha basic information about the sender; the banking agencies expect the bank to know the originators behind it, monitor their returns and complaints, and set limits against the sender’s creditworthiness. Registration is the start of the file, not the file.