Build vs buy collections software: the wrong question

The real cost of an in-house collections system, and the two ways lenders buy instead.

08 September 2026
5 min read

Build your own collections system and you control everything. Buy from a specialist and you give up flexibility. Both of those claims are out of date.

Bespoke collections systems cost far more to build and run than most business cases show. Modern specialist software is far more configurable than most buyers assume. Somewhere between those two facts, "build vs buy" stopped being a useful way to frame the decision.

The question worth asking is narrower and more practical. Where should your specialist engineering effort go?

What an in-house collections system actually costs

Development is the visible number. Salaries, contractors, infrastructure. It goes in the business case, and it is usually the smallest line in the eventual total.

These are the costs that often get missed:

  • Compliance change cycles. Every relevant regulatory update becomes a development ticket, a test cycle and a deployment, on the regulator's deadline rather than yours.
  • Security maintenance. Patching, penetration testing, incident response planning, PCI DSS where payments are involved, UK GDPR throughout. A breach in a collections system is a material event for an FCA-regulated firm.
  • Talent risk. When the lead developer on a bespoke system leaves, the system knowledge goes with them. Replacing it is slow and expensive.
  • Agent efficiency drag. A slow or fragmented agent interface adds handling time to every call. At volume that is a real number, and it feeds attrition in a role that is already hard to recruit for.
  • Quality assurance overhead. Without automatic audit trails, evidencing good outcomes means managers manually reviewing calls and case notes. That is expensive, incomplete, and not what the FCA expects to see.
  • Technical debt. Shortcuts taken under delivery pressure compound. A system that is hard to change becomes a system that cannot change quickly when it has to.

None of this disappears by building in-house. It gets distributed across internal budget lines where nobody adds it up. A vendor subscription makes the cost explicit. An internal build makes it diffuse.

The regulatory clock is not set by your IT roadmap

In March 2026 the FCA replaced more than 40 portfolio letters with nine annual Regulatory Priorities reports. The consumer finance report, published on 17 March, is addressed directly to boards and chief executives. One of its three priorities is that firms support consumers who struggle with debt: removing barriers to forbearance, tailoring debt advice, and communicating clearly enough that customers can make timely, well-informed decisions.

The significant shift is in how that gets tested. The FCA has signalled it will look at customer journeys and outcomes, not just at policy design. Having a forbearance option written down is no longer the point. Being able to show what actually happened, account by account, is.

That sits on top of PS24/2, which strengthened protections for borrowers in financial difficulty in CONC, with an evaluation of the persistent debt intervention due in the second half of 2026.

Each of those developments arrives at a bespoke system as a change request, competing with everything else in the backlog. A specialist vendor does the same work once, across every client, as part of the service.

Configurable is not the same as rigid

The build case usually assumes that buying means accepting someone else's process. Modern collections software does not work that way.

The vendor builds and maintains the components that are complex, high-risk and broadly identical for every lender:

  • cloud-native, event-driven architecture that reacts in real time rather than overnight
  • a workflow and decisioning engine that automates routine work and guides agents through complex cases
  • an agent workspace with the whole case on one screen, including vulnerability flags and contact history
  • a customer self-service portal for payments, repayment plans and secure messaging
  • one data model holding every interaction, so analytics and regulatory reporting are clean
  • security controls and audit trails maintained to current standards

Configuration is where your strategy goes: your treatment paths, your contact rules, your risk appetite, your forbearance ladder. That is the part that differentiates you. The workflow engine underneath it is not.

Two paths, and both of them are buying

Two routes to specialist collections software
Consideration Out of the box Buy and configure
Best for Speed to value, minimal IT resource Distinctive processes, skilled in-house teams
Time to live Weeks Weeks to months, depending on scope
Technical resource Low. Business-led configuration only Medium. Developers extend via API and event streaming
Ongoing flexibility High. Change workflows without code Very high. Extend and integrate as strategy evolves
Compliance risk Low. Specialist handles regulatory updates Low on the core. Your extensions are yours

Out of the box is the right starting point for most lenders. You take a system already carrying UK collections practice and customer journeys, apply your branding and business rules, and go live. Your Head of Collections can test a new payment reminder strategy in an afternoon without raising a ticket.

Larger organisations, and those with genuinely distinctive operations, can go further. Event streaming keeps connected systems in sync as things happen, so a payment, a vulnerability flag or a status change lands everywhere at once. APIs handle on-demand actions. Your developers then spend their time on the integrations and experiences that set you apart, rather than rebuilding workflow engines and payment connectors that already exist.

Five questions worth asking any vendor

  1. Sector depth. Can they explain, operationally rather than in principle, how the system handles vulnerable customer identification, forbearance workflows and Consumer Duty evidencing?
  2. Architecture. Is it genuinely cloud-native and event-driven, or legacy software hosted in the cloud? The difference shows up in how fast a regulatory change can be applied.
  3. Where the record lives. Does the system hold the complete record of collections activity, every communication, arrangement, action and decision with the audit trail, or is it an engagement layer sitting on top of something else? And how does it work with your core banking system, which stays the source of balances and payments?
  4. Implementation track record. How long is a typical deployment, who is on the implementation team, and what happens when something goes wrong after go-live?
  5. Roadmap and AI. A vendor promising full automation today without a clear answer on auditability is worth treating carefully. A vendor who can show you what AI informs, what it decides, and how both are logged and reviewed, is a lower-risk partner.

Where this leaves the decision

Building collections software in-house is not impossible. It is more expensive, slower and riskier than it looks at the point of decision. The developer salaries are visible. The compliance change cycles, the security maintenance, the talent risk, the agent efficiency drag and the technical debt are not.

The lenders getting this right have not chosen the least flexible option. They have put their engineering effort into strategy, customer relationships and integration, and left the workflow engine, the regulatory updates and the security burden with a supplier who builds nothing else. They collect more, they carry less regulatory risk, and their cost to collect goes down.

If you want to see what that looks like in practice, or you are building the internal case for change, we will walk you through it on your own scenarios.

Related resources

Latest resources