On September 15, 2025, TSI announced its acquisition of DebtNext. The reason was an argument about how recovery should be built: the system that governs the work and the capability that performs the work have been designed separately for as long as either has existed, and creditors have been paying for the gap between them.
A recovery control layer is the operational architecture an organization uses to govern inventory, workflows, service providers, exceptions, evidence and performance across its revenue-recovery environment. It sits between the systems of record that create the debt and the execution layer that works it.
A year in, the argument has held up. Here is what we believe.
What do TSI and DebtNext believe about recovery software and operations?
Seven things, and they are all operating principles rather than product claims.
- Software should know where the work is. A recovery leader should be able to name the location and status of every placed account without calling a vendor or opening a portal.
- Workflows should reflect policy. Placement criteria, recall triggers, treatment sequences and hold rules belong in configured workflow, where they run consistently and can be audited.
- Vendors should operate inside observable processes. Placement, activity, exceptions and results should be observable to the client while the work is happening.
- Performance should influence decisions. Scorecards become useful when the data feeds allocation, treatment and strategy decisions on a short cycle.
- Operational evidence should persist. Disputes, media requests, compliance events, consumer contacts and account history need to survive vendor changes.
- Technology should increase client control. Every added system should leave the client with more say over routing, treatment and standards.
- Clients choose how much execution they want from partners. Some want a platform, some want execution, many want both in different segments.
How does the TSI and DebtNext model work?
DebtNext provides the recovery management environment. TSI provides execution capability that can operate alongside it. The client keeps visibility and control.
| Layer | What lives there | Who provides it |
|---|---|---|
| Systems of record | Billing, servicing, EHR, ERP, CRM | The client |
| Recovery control layer | Inventory, rules, workflow, vendor allocation, compliance controls, exceptions, media, disputes, performance, reconciliation | dPlat is a concrete manifestation |
| Execution layer | Digital communication, 1st-party ops, 3rd-party agencies, legal, human operators, AI agents | Client’s vendor network; TSI operates portions |
| Management layer | Performance, risk, compliance, net-back, optimization | The client, using control layer data |
dPlat manages $100M+ in monthly placements. TSI manages $64B+ in receivables across its lines of business and recovered $1.5B+ in calendar 2025, with 20+ sites and 10,000+ agents.
Five questions to ask about your own recovery operations
1. Can you determine where every placed account is right now? 2. How much human work does it take to move an account between treatments or vendors? 3. Can you compare providers using the same data and definitions? 4. When a compliance, media or dispute exception occurs, who sees it and how fast? 5. Can you reconstruct an account’s full history without assembling it from emails, spreadsheets and vendor portals?
FAQ
Is dPlat collection software? No. dPlat is a recovery management environment: inventory, placement and recall, workflow, vendor oversight, reconciliation and audit history.
Does a client have to use TSI for execution? No. Clients configure their own vendor networks and routing rules. TSI managed execution is optional.