ABCs of Third-Party Service Providers and Nested Third-Party Senders

In the previous blog, we discussed the roles and responsibilities of a third-party sender. We understood how funds flow between an originator and recipient with and without the support of a third-party sender. We also understood how third-party processors sometimes collect and send payments. In this blog, we discuss the job of a third-party service provider. We also understand the role of a NESTED third-party sender and how it is different from a conventional/primary third-party sender. Lastly, we shed some light on risk management and relationships between third-party senders and banks.

What are Third-Party Service Providers (TPSPs)?

A Third-Party Service Provider (TPSP) is an organization/individual that offers some services (accounting, editorial, or technology partners) to the participants in an ACH network. In simpler terms, the job of a TPSP is to facilitate the transfer of funds in an ACH process. Modern treasury is an excellent example of a TPSP. Other examples include technology and payment, and solution providers. 

What is the Difference between Third-Party Service Providers (TPSPs) and Third-Party Senders(TPSs)?

The roles of a Third-Party Sender (TPS) and TPSP sound similar. To some extent, they are identical, but one key difference segregates them. 

A TPS DIRECTLY facilitates transaction (flow of funds) – during the transfer process, the funds ($$) flow directly through the bank account of a TPS. So, a TPS (like a payroll processor) sends payment on behalf of the originator (the TPS’s client) using its own and not the originator’s ODFI.

On the other hand, a TPSP INDIRECTLY facilitates the transaction – during the transfer process, the funds ($$) do NOT flow through the TPSP’s bank account. So, the TPSP does NOT hold the funds in its bank account at any point during the transfer process.

Let’s understand this with small examples. 

Example 1: 

Let’s say an organization called “Checkflix” needs to pay its employees their salary every week, and it uses a payroll processor called “Paypop” to carry out this task. 

• Process Flow: The funds go from Checkflix’s bank account to Paypop’s bank account a few days before the Friday (when employees typically receive their salary). On Friday, Paypop sends money from its bank account to the individual accounts of all the Checkflix employees. 
• Conclusion: In this scenario, the funds sit in Paypop’s bank account for a few days before going to the individual bank accounts of Checkflix employees. Here, Paypop acts as a third-party SENDER.
• Real-Life Examples of TPS: Payroll processors 

Example 2: 

Let’s say an organization called “Checkflix” needs to pay its vendor called “Stapler” for office supplies. It uses the payment technology/software called “Techno” to carry out this task.

• Process Flow: The funds go from Checkflix’s bank account automatically to Stapler’s bank account using the recurring billing technology offered by Techno.
• Conclusion: In this scenario, the funds do NOT go to Techno’s bank account on any day. Here, Techno acts as a third-party SERVICE PROVIDER.
• Real-Life Examples of a TPSP: Technology providers like iCheckGateway.com

Note: A few payment processors like iCheckGateway.com have active agreements with several ODFIs. Therefore, they can act as both a TPSP (service provider) and a TPS (sender).

What are Nested TPSs?

A Nested TPS acts similarly to a primary/conventional TPS. The critical difference between a Nested TPS and a TPS is that a Nested TPS maintains a relationship between the originator and the primary TPS. It does NOT have an active relationship with the ODFI. The Nested TPS can disburse amounts to the TPS on behalf of the originator. Similarly, it can also collect funds from the TPS on behalf of the receiver. 

Here’s how the workflow of funds looks like if a Nested TPS is involved in the transfer process:

• Step 1: The Originator sends the origination agreement to the Nested Third-Party Sender.
• Step 2: The Nested TPS verifies and sends the agreement to the Third-Party Sender. Here the Nested TPS has an active relationship with a bank but NOT with the ODFI. 
• Step 3: The TPS verifies and sends the agreement plus the ACH file to the ODFI on behalf of the Nested TPS.
• Step 4: The ODFI reviews, batches, and forwards the agreements (usually in bulk) to the ACH Operator. 
• Step 4: The operator reviews the agreements and forwards them to the respective RDFI. 
• Step 5: The RDFI forwards the agreement to the Receiver of funds. 
• Step 6: The Receiver then shares the completed and verified authorization agreement with the Originator.

Banks-TPS Relationships and Risk Management

Involving a TPS or a Nested TPS in the transfer process opens up the originator and ODFI to several risks. The risk of confronting a loophole or a security flaw increases since money flows through more hands before reaching the receiver. In such situations, the participants in the cash flow need to adopt the following security measures:

• Conduct Risk Assessment: The TPS should regularly conduct ACH compliance audits and risk assessments. It should then submit the reports to the ODFI and the originator. Moreover, Nacha is directly involved in monitoring operations of a TPS-operated ACH process, so it can also request the compliance audit results. 
• Implement Risk Management Program: Such programs clearly outline the steps that all network participants should take in the event of risks detected.  
• Implement the Right Infrastructure and Expertise (for Banks): The banks need to establish a hierarchy and identify individuals who would handle TPS relationships. Facing trouble identifying a third-party sender? Leverage this third-party sender identification tool by Nacha for a quick result. 
• Enhanced Due Diligence and Underwriting (for Banks): Banks should have a well-established process to vet, select, partner, and identify suitable third-party senders. They should also verify the types of customers (originators) that the TPS holds and the vetting process it goes through before onboarding new ones.
• Active Monitoring: An active monitoring of the customers and the origination agreements created by the TPS further strengthens the relationship. With a functional risk management portal, the bank, auditors, and the TPSs can stay updated with the latest rule changes and compliance requirements. The bank should look for red flags in SEC code usage and monitor return dates while conducting periodic audits. It should also verify and track unusually high return rates and transfer volumes. 
• On-Going TPS Specific Training: All TPSs are not the same. They require different parameters, controls, and risk management techniques. Auditors usually expect the TPS to undergo extensive audit and risk assessment training specific to that particular TPS. A TPS should also have a good understanding of the inner workings of the ACH network and Nacha operating rules to facilitate faster and more seamless transactions.  
• Correct Documentation of Credit Files: Transmitting entries via ACH payment in Nested third-party sender relationships can get complicated quickly.Proper documentation and processing of credit files make tracking and auditing simple for all the network participants.
•