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.
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 solution providers.
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, the 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).
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.
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:
The ACH origination agreements are set to undergo significant changes from September 2022. Learn more about the Nacha recommended TPS risk assessment practices on the official Nacha website here.
The right kind of helpful third-party service providers can reduce hassle and automate several processes both on the banking and originator fronts. The wrong type can create several dangerous loopholes and unnecessary complications in the transfer process. While selecting and partnering with a new TPSP, both banks and originators should take specific measures to prevent risk and facilitate open communication. Learn more about the various technological advancements in the payment processing space by downloading our product catalog here.